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Abstract 

System  protection  mechanisms  such  as  access  controls 
can  befooled  by  authorized  but  malicious  users ,  masquer¬ 
aders ;  and  misfeasors.  Intrusion  detection  techniques  are 
therefore  used  to  supplement  them.  However,  damage  could 
have  occurred  before  an  intrusion  is  detected.  In  many  com¬ 
puting  systems  the  requirement  for  a  high  degree  of  sound¬ 
ness  of  intrusion  reporting  can  yield  poor  performance  in 
detecting  intrusions ,  and  can  cause  long  detection  latency. 
As  a  result ,  serious  damage  can  be  caused  either  because 
many  intrusions  are  never  detected  or  because  the  average 
detection  latency  is  too  long.  The  process  of  bounding  the 
damage  caused  by  intrusions  during  the  process  of  intru¬ 
sion  detection  is  referred  to  as  intrusion  confinement  We 
justify  the  necessity  for  intrusion  confinement  during  detec¬ 
tion  by  a  probabilistic  analysis  model ,  and  propose  a  gen¬ 
eral  solution  to  achieve  intrusion  confinement.  The  crux 
of  the  solution  is  to  isolate  likely  suspicious  actions  before 
a  definite  determination  of  intrusion  is  reported.  We  also 
present  a  concrete  isolation  protocol  in  the  file  system  con¬ 
text  to  evaluate  the  feasibility  of  the  general  solution ,  which 
can  be  applied  in  many  types  of  information  systems. 


*  Jajodia  and  McCollum  were  partially  supported  by  Rome  Laboratory, 
Air  Force  Material  Command,  USAF,  under  agreement  number  F30602- 
97-1-0139. 


1  Introduction 


Recently  there  has  been  increasing  emphasis  on  supple¬ 
menting  protection  of  networks  and  information  systems 
with  intrusion  detection  [Lun93,  MHL94,  LM98]  and  nu¬ 
merous  intrusion  detection  products  have  emerged  com¬ 
mercially.  Recognizing  that  access  controls,  filtering,  and 
other  protection  mechanisms  can  be  defeated  or  bypassed 
by  would-be  attackers  who  take  advantage  of  remaining 
vulnerabilities,  intrusion  detection  systems  monitor  system 
or  network  activity  to  discover  attempts  to  disrupt  or  gain 
illicit  access  to  systems.  Intrusion  detection  must  be  con¬ 
cerned  both  with  attempts  by  external  penetrators  to  enter  or 
interfere  with  the  system  and  by  authorized  users  to  exceed 
their  legitimate  access  or  abuse  the  system  in  some  way. 
The  latter  case  also  includes  seemingly  authorized  users, 
such  as  masqueraders  operating  under  another  user’s  iden¬ 
tification  (id)  and  password,  or  outside  attackers  who  suc¬ 
cessfully  gained  system  access  but  eluded  detection  of  the 
method  of  entry.  The  methodology  of  intrusion  detection 
can  be  roughly  classed  as  being  either  based  on  statistical 
profiles  or  on  known  patterns  of  attacks,  called  signatures. 

Statistical  profile-based  system  compare  relevant  data  by 
statistical  or  other  methods  to  representative  profiles  of  nor¬ 
mal,  expected  activity  on  the  system  or  network.  Devia¬ 
tions  indicate  suspicious  behavior.  In  these  systems,  there 
are  stringent  requirements  on  not  only  reporting  an  intru¬ 
sion  accurately  (this  is  necessary  because  abnormal  behav¬ 
ior  is  not  always  an  intrusion)  but  also  detecting  as  many 
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intrusions  as  possible  (usually,  not  all  intrusions  can  be  de¬ 
tected).  However,  these  two  requirements  can  often  result 
in  conflicting  design  goals. 

To  make  this  tangible,  consider  a  system  where  short¬ 
term  behavior  of  a  user  Ui  is  audited  and  compared  to  Uf  s 
profile,  which  represents  Ufs  normal  long-term  behavior. 
Whenever  Ufs  short-term  behavior  is  sufficiently  unlike 
Ui$  long-term  behavior,  a  warning  is  raised.  The  devia¬ 
tion  of  Ui$  short-term  behavior  from  his  long-term  behav¬ 
ior  can  be  quantified  with  the  distance,  denoted  d,  in  an 
N-dimensional  space  from  the  point  defined  by  a  vector  of 
intrusion-detection  measures  that  represents  Ufs  short-term 
behavior,  to  the  point  defined  by  a  vector  that  represents 
Uf s  long-term  behavior.  Now  the  problem  is:  How  long  a 
d  is  sufficient? 

Based  on  the  assumption  that  the  more  significant  the 
deviation,  the  larger  the  possibility  that  Ui  s  short-term  be¬ 
havior  is  an  intrusion,  in  order  to  ensure  a  high  degree  of 
soundness  of  intrusion  reporting  (the  soundness  can  be  mea¬ 
sured  by  the  probability  that  when  a  short-term  behavior  is 
reported  as  an  intrusion  it  is  really  an  intrusion),  d  needs 
to  be  made  sufficiently  long.  However,  as  d  gets  longer, 
the  number  of  intrusions  that  can  be  detected  decreases  be¬ 
cause  intrusions  characterized  by  gradual  anomaly  can  be 
overlooked  by  the  detector  (a  formal  analysis  is  presented  in 
Section  2),  in  which  case  many  intruders  may  stay  at  large 
and  cause  substantial  damage.  Moreover,  even  for  an  intru¬ 
sion  which  is  characterized  by  significant  anomaly,  choos¬ 
ing  a  very  long  d  may  still  cause  a  long  latency  of  the  de¬ 
tection.  As  a  result,  substantial  damage  can  be  caused  by  an 
intruder  within  the  latency.  Choosing  a  shorter  d  can  mit¬ 
igate  these  problems;  however,  the  soundness  of  intrusion 
reporting  can  be  dramatically  degraded.  In  other  words,  in¬ 
nocent  users  may  be  mistaken  for  malicious  ones  and  legal 
service  requests  may  be  denied  in  many  situations.  This  is 
because  trustworthy  users  may  gradually  change  their  be¬ 
havior  in  a  non-significant  way. 

With  the  requirement  of  a  given  degree  of  soundness,  the 
process  of  bounding  the  damage  caused  by  undetected  in¬ 
trusions  and/or  detected  intrusions  during  their  latencies  is 
referred  to  as  intrusion  confinement .  Intrusion  confinement 
also  encompasses  corresponding  strategies  and  mechanisms 
taken  to  enable  the  process. 

Signature-based  detection  examines  sniffer  logs,  audit 
data,  or  other  data  sources  for  evidence  of  operations,  se¬ 
quences,  or  techniques  known  to  be  used  in  particular  types 
of  attacks.  Signature-based  detection  techniques  cannot  be 
used  to  detect  new,  unanticipated  patterns  that  could  be 
detected  by  statistical  profile-based  detection  techniques. 
However,  they  are  used  to  detect  known  attacks.  Intrusion 
confinement  can  also  be  used  in  association  with  signature- 


based  detection.  We  can  view  a  signature  as  a  sequence  of 
actions,  as  well  as  the  state  transitions  associated  with  these 
actions.  Since  a  prefix  of  a  signature  is  usually  not  a  signa¬ 
ture  (otherwise  the  signature  can  be  shorter),  by  the  time  a 
signature  is  matched  serious  damage  may  have  already  been 
caused.  Since  in  many  situations  such  damage  may  not  be 
recoverable,  it  would  be  desirable  if  we  could  avoid  such 
damage  without  causing  denial  of  service. 

The  first  contribution  of  this  paper  is  that  it  gives  a  sim¬ 
ple  probabilistic  model  to  measure  the  effectiveness  of  an 
intrusion  detection  system  and  to  justify  the  necessity  of  in¬ 
trusion  confinement.  Based  on  the  degree  of  effectiveness, 
the  system  security  officer  (SSO)  can  decide  whether  to  en¬ 
force  intrusion  confinement  and,  if  so,  what  mechanisms 
and  strategies  to  apply  for  intrusion  confinement. 

The  second  contribution  of  the  paper  is  that  it  gives  a 
general  solution  of  intrusion  confinement  which  is  closely 
coupled  with  intrusion  detection  mechanisms  and  can  be 
applied  in  many  kinds  of  information  systems.  The  basic 
idea  is  to  isolate  suspicious  actions  before  an  intrusion  is 
reported.  However,  the  decisions  about  when  to  isolate  and 
which  actions  to  isolate  are  made  by  exploiting  the  func¬ 
tionality  of  intrusion  detection  facilities.  Since  suspicious 
behavior  may  turn  out  to  be  an  intrusion  and  cause  damage, 
such  isolation  can  bound  the  potential  damage. 

When  a  suspicious  behavior  is  discovered,  the  intrusion 
detector  or  the  SSO  must  decide  how  to  react  and  whether 
to  allow  continued  access  by  the  associated  subject,  say  B , 
such  as  a  process,  a  user,  or  a  host.  The  system  can  let 
B  continue  to  access  the  system  just  as  systems  do  today, 
risking  further  damage,  or  take  action  to  deny  B  contin¬ 
ued  access  to  the  system,  which  may  also  be  undesirable, 
for  a  couple  of  reasons.  Further  investigation  may  show 
that  the  suspicious  behavior  was  actually  unusual  but  legit¬ 
imate  activity.  If  this  is  the  case,  denying  B  access  could 
result  in  unwarranted  denial  of  service.  It  is  even  possible 
that  an  attacker  is  intentionally  spoofing  B  to  provoke  a  de¬ 
nial  of  service  response  against  B.  On  the  other  hand,  if 
B  proves  guilty,  immediately  denying  access  to  the  system 
may  mean  losing  the  opportunity  to  gather  more  informa¬ 
tion  that  would  help  identify  the  attacker  and  the  objectives 
of  the  attack.  Experience  with  system  and  network  pene¬ 
trations  has  shown  the  usefulness  of  another  alternative  of 
intrusion  confinement:  isolation. 

Isolating  B  transparently  into  a  separate  environment 
which  still  appears  to  B  to  be  the  actual  system  allows  B's 
activities  to  be  kept  under  surveillance  without  risking  fur¬ 
ther  harm  to  the  system.  An  isolation  strategy  that  has  been 
used  in  such  instances  is  known  as  fishbowling.  Fishbowl¬ 
ing  involves  setting  up  a  separate  lookalike  host  or  file  sys¬ 
tem  and  transparently  redirecting  the  suspicious  entity’s  re- 
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quests  to  it.  This  approach  allows  the  incident  to  be  further 
studied  to  determine  the  real  source,  nature,  and  goal  of  the 
activity,  but  has  some  limitations,  particularly  when  consid¬ 
ered  at  the  application  level.  First,  the  substitute  host  or  file 
system  is  essentially  sacrificed  during  the  suspected  attack 
to  monitor  B ,  consuming  significant  resources  that  may  be 
scarce.  Second,  since  B  is  cut  off  from  the  real  system,  if  B 
proves  innocent,  denial  of  service  could  still  be  a  problem. 
While  some  types  of  service  B  receives  from  the  substitute, 
fishbowl  system  may  be  adequate,  in  other  cases  the  lack 
of  interaction  with  the  real  system’s  resources  may  prevent 
B  from  continuing  to  produce  valid  results.  On  the  other 
hand,  if  the  semantics  of  the  application  are  such  that  B 
can  continue  producing  valid  work,  this  work  will  be  lost 
when  the  incident  concludes  even  if  B  is  deemed  innocent 
and  reconnected  to  the  real  system.  The  fishbowling  mech¬ 
anism  makes  no  provision  for  re-merging  updates  from  the 
substitute,  fishbowl  system  back  into  the  real  system. 

Within  the  general  solution,  we  offer  an  isolation  strat¬ 
egy  that,  while  in  some  sense  a  counterpart  to  fishbowling, 
takes  advantage  of  action  semantics  to  avoid  some  of  these 
limitations.  In  this  isolation  approach,  as  in  the  case  of  fish¬ 
bowling,  when  B  comes  under  suspicion,  we  let  B  con¬ 
tinue  working  while  we  attempt  to  determine  whether  there 
is  anything  to  worry  about.  At  the  same  time,  we  isolate 
the  system  from  any  further  damage  B  might  have  in  mind. 
However,  we  provide  this  isolation  without  consuming  du¬ 
plicate  resources  to  construct  an  entirely  separate  environ¬ 
ment,  we  allow  options  for  partial  interaction  across  the 
boundary,  and  we  provide  algorithms  for  smoothly  merging 
Bys  work  back  into  the  real  system  should  B  prove  inno¬ 
cent. 

We  illustrate  our  approach  in  the  context  of  a  file  system. 
Consider  the  following  attack  scenario:  Suppose  a  user  B 
of  the  file  system  comes  under  suspicion.  To  let  B  con¬ 
tinue  working  and  at  the  same  time  to  isolate  the  file  system 
from  any  further  damage  from  By  we  propose  to  create  an 
on-the-fly  “separate  file  store”  for  the  user  B.  All  accesses 
of  B  are  then  directed  only  to  the  separate  suspicious  file 
store,  while  actions  from  other  users  are  applied  to  the  main 
file  store.  The  two  stores  may  become  inconsistent  over 
time.  Any  inconsistency  can  be  resolved  when  a  determi¬ 
nation  is  reached  about  whether  the  suspicious  user  B  is 
actually  malevolent  or  is  innocent  after  all.  If  B  turns  out 
to  be  malicious,  the  suspicious  file  store  can  be  discarded  to 
protect  the  main  store  from  harm.  If  B  turns  out  to  be  in¬ 
nocent,  B’s  updates  in  the  suspicious  store  will  be  merged 
back  into  the  main  store;  conflicting  updates  will  be  iden¬ 
tified  so  that  conflicts  can  then  be  resolved.  The  benefit  of 
this  scheme  is  that  work  can  continue  while  the  investiga¬ 
tion  is  in  progress.  Disruption  of  the  system’s  operations  is 
kept  to  a  minimum  if  B  is  innocent,  but  B  would  have  been 


prevented  from  doing  further  damage  to  the  system  if  B  is 
guilty. 

This  work  has  relevance  to  information  warfare  (IW) 
defense  [AJMB97,  GSM96,  MG96a,  MG96b,  PG99].  As 
pointed  out  by  Ammann,  et  al.  [AJMB97],  information  war¬ 
fare  defense  does  everything  possible  to  prevent  attacks 
from  succeeding,  but  it  also  recognizes  that  attempting  to 
prevent  information  attack  is  insufficient;  attacks  that  are 
successful  to  some  degree  must  be  recognized  as  unavoid¬ 
able,  and  comprehensive  support  for  identifying  and  re¬ 
sponding  to  attacks  is  required. 

The  rest  of  the  paper  is  organized  as  follows.  In  Sections 
2  and  3,  we  use  a  probabilistic  model  to  justify  the  neces¬ 
sity  of  intrusion  confinement.  Section  4  presents  a  general 
solution  of  intrusion  confinement.  In  Section  5,  we  evaluate 
the  feasibility  of  our  solution  by  presenting  a  concrete  iso¬ 
lation  protocol  which  is  applied  to  a  file  system.  Section  6 
discusses  related  work.  In  Section  7,  we  conclude  the  paper. 

2  Why  Is  Intrusion  Confinement  Necessary? 

Informally,  suspicious  behavior  is  the  behavior  that  may 
have  already  caused  some  damage,  or  may  cause  some  dam¬ 
age  later  on,  but  was  not  reported  as  an  intrusion  when  it 
happened.  In  our  model,  suspicious  behavior  emerges  in 
four  situations: 

1.  In  statistical  profile-based  detection,  as  discussed 
above,  in  order  to  get  a  high  degree  of  soundness  of 
intrusion  reporting,  some  intrusions  characterized  by 
gradual  deviations  may  stay  undetected.  The  corre¬ 
sponding  behaviors  can  be  reported  as  suspicious. 

2.  In  statistical  profile-based  detection,  for  a  detection 
with  a  long  latency,  the  corresponding  behavior  can  be 
reported  as  suspicious  in  the  middle  of  the  latency. 

3.  In  statistical  profile-based  detection,  legitimate  behav¬ 
ior  can  be  reported  as  suspicious  if  it  is  sufficiently  un¬ 
like  the  corresponding  profile. 

4.  In  signature-based  detection,  partial  matching  of  a  sig¬ 
nature  can  trigger  a  report  of  suspicious  behavior. 

In  the  remainder  of  this  section,  we  present  a  probabilis¬ 
tic  model  for  justifying  the  necessity  of  intrusion  confine¬ 
ment.  Note  that  all  of  the  statistics  used  in  this  section  were 
computed  based  on  the  audit  trail,  where  the  entire  intrusion 
history  is  assumed  to  be  recorded. 
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2.1  Intrusion  Confinement  for  Statistical  Profile 
based  Detection 


Consider  an  statistical  profile-based  detection  system 
where  a  user  Ut  accesses  the  system  through  sessions.  A 
session  of  Ut  begins  when  Ui  logs  in  and  ends  when  Ui  logs 
out.  A  behavior  of  Ui  is  a  sequence  of  actions  that  can  last 
across  the  boundaries  of  sessions.  A  short-term  behavior  of 
Ui  is  a  behavior  that  is  composed  of  a  sequence  of  Ui  s  most 
recent  actions.  The  length  of  the  sequence,  which  is  usually 
small,  is  determined  by  the  SSO.  In  contrast,  a  long-term 
behavior  of  Ui  is  also  a  sequence  of  Ui  s  most  recent  actions 
but  it  is  much  longer  than  the  short-term  behavior.  We  as¬ 
sume  the  intrusion  detector  is  triggered  in  every  m  actions 
(or  m  audit  records),  that  is,  after  m  new  actions  are  exe¬ 
cuted,  both  the  current  short-term  behavior  and  long-term 
behavior  of  Ui  will  be  upgraded  and  the  deviation  of  the 
new  short-term  behavior  from  the  new  long-term  behavior 
will  be  computed.  When  a  short-term  behavior  is  upgraded, 
its  oldest  m  actions  will  be  discarded  and  the  newest  m  ac¬ 
tions  will  be  added. 

In  the  following  presentation,  we  use  “behavior”  to  de¬ 
note  a  short-term  behavior  for  brevity.  The  access  his¬ 
tory  of  Ui  can  be  specified  as  a  sequence  of  behaviors,  al¬ 
though  two  behaviors  in  the  sequence  can  have  multiple 
actions  in  common.  We  model  the  access  history  of  Ui 
as  a  discrete  stochastic  process  x(t)  where  x(U ),  which 
indicates  the  type  of  the  behavior  of  Ui  at  time  t{,  can 
take  one  of  three  possible  values,  namely,  LEGITIMATE, 
SUSPICIOUS  and  INTRUSION,  usually  with  different 
probabilities.  It  should  be  noted  that  x(t)  is  theoretically  not 
an  independent  process  because:  (1)  the  behavior  of  Ui  at 
time  i  is  a  part  of  the  long-term  behavior  that  is  the  pro¬ 
file  of  the  behavior  of  Ui  at  time  ti,  hence  x(t)  is  affected  by 
x  (t - 1) ;  (2)  the  behavior  of  Ui  at  times  and  U  can  share 

multiple  actions;  (3)  the  behavior  of  Ui  at  times  U-\  and  U 
can  have  semantic  relationships.  For  example,  a  LATEX 
command  is  usually  followed  by  a  DVIPS  command  when 
a  TEX  file  is  compiled.  However,  it  is  reasonable  to  sim¬ 
plify  the  model  by  viewing  x{t)  as  an  independent  process 
in  many  situations  when  the  profile  covers  a  relatively  long 
long-term  behavior  and  when  the  overlap  of  neighbored  be¬ 
haviors  is  only  a  small  part  of  each  behavior  because  at  this 
point  the  effect  of  the  behavior  of  Ui  at  time  i  on  the 
profile  is  too  weak  to  affect  x(f),  and  neighbored  behaviors 
can  be  viewed  as  having  no  overlaps.  For  simplicity,  we 
model  x(t)  in  the  following  presentation  as  an  independent 
discrete  stochastic  process.  In  addition,  we  assume  that  the 
access  histories  of  any  two  users  Ui  and  Uj  are  independent 
of  each  other.  Note  that  our  goal  is  showing  that  intrusion 
confinement  is  necessary,  as  opposed  to  evaluating  accu¬ 
rately  the  performance  of  intrusion  detection  systems. 


We  assume  that  statistical  methods,  such  as  the  meth¬ 
ods  proposed  in  NIDES  [JV94],  are  used  in  the  system. 
We  assume  that  both  the  short-term  and  long-term  behav¬ 
iors  of  Ui  at  time  t  are  described  by  a  vector  of  n  intru¬ 
sion  detection  measures  (or  variables).  We  denote  them  as 
v*s  =  (v5i,-..,t;5n)  andvj  =  (%, ..., vin), respectively.  The 
deviation  of  v$  from  vi  is  specified  by  the  distance,  denoted 
d{v$,  vi),  from  the  point  defined  by  v*$  to  the  point  defined 
by  vi  in  the  n-d imension  space.  We  further  assume  that  the 
longer  d(vs,vi)  is,  the  bigger  the  probability  that  v*s  is  an 
intrusion.  In  the  system,  a  warning  is  raised  if  d(v*S7vi)  is 
sufficiently  long.  Interested  readers  can  refer  to  [JV94]  for 
such  details  as  to  which  measures  can  be  used,  how  these 
measures  are  quantified,  and  how  d(vs,  vi)  is  computed. 

We  evaluate  the  effectiveness  of  such  an  statistical 
profile-based  detection  system  with  two  measures: 

•  The  rate  of  detection,  denoted  Rd ,  is  the  percentage  of 
the  intrusions  that  can  be  detected  among  all  of  the  in¬ 
trusions.  Rd  indicates  the  general  ability  of  a  detector 
in  detecting  intrusions. 

•  The  rate  of  errors ,  denoted  Re ,  is  the  probability  that 
a  reported  intrusion  is  actually  not  an  intrusion.  Re 
indicates  the  soundness  of  a  detector.  The  smaller  Re 
is,  the  higher  degree  of  soundness  is  achieved. 

Rd  and  Re  can  be  formalized  based  on  the  parameters  listed 
in  Figure  1  as  follows.  We  introduce  Ds ,  Ps ,  and  As  to 
model  intrusion  confinement.  Note  that  Ds  is  less  than  Di\ 
hence,  a  reported  intrusion  must  be  suspicious.  The  basic 
meaning  of  these  parameters  is  shown  in  Figure  2. 

r,  — _ _ 

A,Pa+(l-A,)Pg 

Re  =  1  -  Pi 


Example  1  Assume  the  SSO  decides  that  Pi  should  be  at 
least  0.90  to  ensure  a  high  degree  of  soundness.  As  a  result , 
the  corresponding  Di  can  be  determined  to  ensure  such  a 
Pi.  However,  ensuring  such  a  high  Pi  does  not  mean  we 
can  also  detect  most  of  the  intrusions.  If  we  consider  the 
situation  where  Ai  =  0.01,  As  =  0.10,  Ps  =  0.50,  and 
Pg  —  0.002,  then  the  rate  of  detection  Rd  —  0.174,  which 
is  very  low.  On  the  other  hand,  if  we  decrease  the  value  of 
Pi  to  detect  more  intrusions,  for  example,  we  set  the  value  of 
Di  to  that  ofD$,  then  the  rate  of  error  Re  =  1  —  Ps  =  0.50, 
which  is  too  high. 

The  above  example  shows  that  in  many  situations  if  we 
want  to  achieve  a  low  rate  of  errors,  then  we  cannot  achieve 
a  high  rate  of  detection.  Therefore,  the  two  requirements 
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Di 

the  value  of  distance  such  that  if  vj)  >  Diy  then  v~s  is  reported  as  an  intrusion. 

Pi 

the  probability  that  when  a  behavior  is  reported  as  an  intrusion, 
that  is,  d{vs,  v J)  >  Du  it  is  really  an  intrusion. 

Ds 

the  value  of  distance  such  that  if  d(v*Sy  v\)  >  DSy  then  v*s  is  reported  as  suspicious. 

Ps 

the  probability  that  when  a  behavior  is  reported  as  suspicious,  that  is, 
d{v*s  ,vl)  >  Ds ,  it  is  an  intrusion. 

Ai 

the  probability  that  a  behavior  deviates  from  the  corresponding  long-term  behavior 
with  d(v*s,  vi)  >  Di . 

As 

the  probability  that  a  behavior  deviates  from  the  corresponding  long-term  behavior 
with  d(v*S:  vi)  >  Ds. 

P9 

the  probability  that  a  behavior  with  <  Ds  is  an  intrusion. 

Figure  1.  Evaluation  Parameters  for  an  Statistical  Profile-based  Detection  System 


the  system  from  the  damage  caused  by  most  of  the  intru¬ 
sions.  The  effectiveness  of  isolation  can  be  measured  by  the 
rate  of  isolation,  denoted  il; ,  which  is  the  percentage  of  the 
intrusions  that  will  be  isolated  among  all  of  the  intrusions. 
Ri  is  formalized  as  follows: 

jr.  = _ A  lE* _ 

^  A3P3  +  (l-A3)Pg 

In  Example  1,  if  we  keep  Pi  at  0.90,  Ri  is  96.5%. 

2.2  Intrusion  Confinement  for  Signature-based 
Detection 


Figure  2.  Classification  of  User  Behaviors 


can  often  result  in  conflicting  design  goals.  Since  the  rate 
of  errors  cannot  be  very  high  because  otherwise  substan¬ 
tial  legitimate  service  requests  will  be  denied,  a  high  rate  of 
detection  cannot  be  achieved  in  many  cases.  Thus,  many  in¬ 
trusions  can  stay  undetected  (in  Example  1,  the  undetected 
intrusion  rate  is  82.6%),  and  the  latency  of  an  intrusion  can 
be  very  long.  As  a  result,  serious  damage  can  be  caused. 

Intrusion  confinement  can  bound  this  damage.  As  shown 
in  Figure  1,  the  set  of  actions  that  should  be  isolated  can 
be  specified  as  follows.  Note  that  since  Ds  is  determined 
by  the  SSO  based  on  the  value  of  Ps  he  prefers,  intrusion 
confinement  systems  can  be  flexibly  configured. 

Definition  1  A  short-term  behavior  described  by  vs  is  sus¬ 
picious  if  d{vs,vi)  >  Ds.  Here,  Ds  is  determined  by  the 
value  of  Ps ,  which  is  chosen  by  the  SSO. 

By  isolating  suspicious  behaviors,  we  can  often  protect 


We  specify  a  signature  as  a  sequence  of  events  lead¬ 
ing  from  an  initial  limited  access  state  to  a  final  compro¬ 
mised  state  [PK92,  Ilg93,  IKP95,  SG91,  SG97,  LWJ98]. 
Each  event  causes  a  state  transition  from  one  state  to  an¬ 
other  state.  We  identify  a  signature  with  length  n,  denoted 
Sig(n)y  as  Sig(n )  =  soExSi...En$ny  where  Ei  is  an  event 
and  Si  is  a  state,  and  Ei  causes  the  state  transition  from  i 
to  S{.  For  simplicity,  intra-event  conditions  are  not  explic¬ 
itly  shown  in  Sig(n)y  although  they  are  usually  part  of  a 
signature. 

A  partial  matching  of  a  signature  Sig{n)  is  a  sequence 
of  events  that  matches  a  prefix  of  Sig(n).  According  to 
previous  discussion,  a  partial  matching  is  usually  not  an  in¬ 
trusion.  However,  it  can  predict  that  an  intrusion  specified 
by  Sig{n)  may  occur.  The  accuracy  of  the  prediction  of 
a  partial  matching,  denoted  soEiSi...Emsmy  can  be  mea¬ 
sured  by  the  following  parameter: 

Pm  :  the  probability  that  the  partial  matching  can  lead  to 
an  intrusion  later.  Assume  the  number  of  the  behaviors 
that  match  the  prefix  is  Np  and  the  number  of  the  intru¬ 
sions  that  match  the  prefix  is  Niy  then  Pm  =  Ni/Np. 
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Intrusion  confinement  in  signature-based  detection  is 
necessary  because  when  an  intrusion  is  reported,  serious 
damage  may  have  already  been  caused  by  the  intrusion.  In 
signature-based  detection,  the  set  of  actions  that  should  be 
isolated  is  defined  as  follows.  Isolating  suspicious  behavior 
can  surely  confine  damage  in  signature-based  detection  be¬ 
cause  the  behavior  that  is  actually  an  intrusion  will,  with  a 
high  probability,  be  prevented  from  doing  harm  to  the  sys¬ 
tem. 

Definition  2  In  signature-based  detection,  a  behavior  is 
suspicious  if  it  matches  the  prefix  of  a  signature  but  not 
the  whole  signature,  and  Pm  of  the  prefix  is  greater  than 
or  equal  to  a  threshold  that  is  determined  by  the  SSO. 


3  When  Should  Intrusion  Confinement  Be 
Enforced? 


The  decision  of  whether  to  enforce  intrusion  confine¬ 
ment  depends  on  the  amount  of  damage  that  can  be  caused. 
The  more  serious  the  damage  is,  the  more  efforts  the  SSO 
would  like  to  take.  In  signature-based  detection,  the  de¬ 
cision  of  whether  to  enforce  intrusion  confinement  on  a 
known  attack  that  is  specified  by  a  signature  is  dependent 
on  the  seriousness  of  the  damage  that  will  be  caused  by 
the  attack  and  the  value  of  Pm  for  each  prefix  of  the  sig¬ 
nature.  For  example,  if  the  damage  is  strongly  undesirable, 
and  there  exists  a  prefix  whose  Pm  is  sufficiently  large,  then 
intrusion  confinement  can  be  enforced  by  isolating  the  be¬ 
havior  that  matches  the  prefix. 

In  statistical  profile-based  detection,  however,  it  can  be 
tricky  to  make  the  decision.  As  shown  in  Section  2,  since 
degrading  the  requirement  on  Re  (the  rate  of  errors)  usually 
can  improve  Rd  (the  rate  of  detection),  the  SSO  may  want 
to  find  a  trade-off  between  Re  and  Rd ;  thus,  the  cost  of  iso¬ 
lation  would  be  avoided.  However,  a  satisfactory  trade-off 
may  not  be  achievable  in  some  systems  since  the  relation¬ 
ship  between  these  two  effectiveness  measures  can  dramat¬ 
ically  differ  from  one  system  to  another. 

Consider  two  systems  with  the  same  set  of  parameters 
and  the  same  associated  values  as  in  Example  1.  When  Pi 
is  degraded  from  0.90  to  0.85  in  both  of  the  systems,  the 
other  parameters  may  take  the  values  that  are  listed  in  the 
following  table.  It  is  easy  to  get  the  following  result:  In  sys¬ 
tem  1,  Rd  =  0.82  and  Re  =  0.15;  In  system  2,  Rd  =  0.33 
and  Re  =  0.15.  It  is  clear  that  when  P{  is  degraded  to  0.85, 
system  1  performs  much  better  than  system  2.  At  a  result, 
the  SSO  may  need  only  to  enforce  intrusion  confinement  in 
system  2. 


System  No. 

Pi 

Ps 

Ai 

p» 

1 

0.85 

0.50 

0.05 

0.10 

0.002 

2 

0.85 

0.50 

0.02 

0.10 

0.002 

It  should  be  noted  that  the  relationship  between  Re  and 
Rd  is  influenced  by  many  factors,  such  as  the  distribution 
of  the  number  of  intrusions  on  the  distance  d{vs,v\)  and 
the  distribution  of  the  number  of  behaviors  on  the  distance 
d{v*s,vi).  Three  typical  kinds  of  relationships  between  Re 
and  Rd  are  specified  as  follows  (here,  a  and  b  are  real  num¬ 
bers): 

•  Re  —  1  -ae(b~RdK  In  this  case,  intrusion  confinement 
is  very  necessary  since  a  small  improvement  in  Rd  can 
cause  a  significant  degradation  of  Re. 

•  Re  =  1  —  (a  —  bRd).  In  this  case,  if  b  is  large,  then 
intrusion  confinement  is  necessary;  if  b  is  small,  then 
a  satisfactory  trade-off  between  Re  and  Rd  is  achiev¬ 
able. 

•  Re  =  1  —  alog(f>  -  Rd)-  In  this  case,  a  satisfactory 
trade-off  is  usually  achievable  since  a  small  degrada¬ 
tion  of  Re  can  cause  a  significant  improvement  of  Rd- 

Of  course,  there  are  many  systems  in  which  the  relationship 
between  Re  and  Rd  is  none  of  these.  However,  the  SSO  can 
make  a  sound  decision  by  a  similar  analysis. 

4  How  Can  Intrusion  Confinement  Be  En¬ 
forced? 

4.1  Architecture  Support 

The  architecture  of  an  intrusion  confinement  system 
from  the  perspective  of  information  warfare  [AJMB97]  is 
shown  in  Figure  3. 

The  Policy  Enforcement  Manager  enforces  the  access 
controls  in  accordance  with  the  system  security  policy  on 
every  access  request.  We  assume  no  data  access  can  bypass 
it.  We  further  assume  that  users’  accesses  will  be  audited  in 
the  audit  trail  For  database  systems  and  for  transactional 
file  systems,  users’  accesses  on  such  data  objects  as  tables 
and  files  are  usually  recorded  in  specific  logs  maintained  for 
recovery  purposes,  instead  of  the  audit  trail.  For  simplicity; 
these  logs  are  not  explicitly  shown  in  Figure  3;  we  assume 
that  they  are  associated  with  each  data  version. 

The  Intrusion  Detection  and  Confinement  Manager  ap¬ 
plies  either  statistical  profile-based  detection  techniques  or 
signature-based  detection  techniques,  or  both  to  identify 
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Figure  3.  Architecture  of  the  Intrusion  Con¬ 
finement  System 


suspicious  behavior  as  well  as  intrusions.  The  detection  is 
typically  processed  based  on  the  information  provided  by 
the  audit  trail  and  the  logs  associated  with  each  data  ver¬ 
sion. 

When  a  suspicious  behavior  is  detected,  the  correspond¬ 
ing  user  is  marked  suspicious .  At  this  point,  first  we  need  to 
deal  with  the  effects  that  the  user  has  already  made  on  the 
Main  Data  Version  because  these  effects  may  have  already 
caused  some  damage.  In  signature-based  detection  systems, 
we  can  accept  these  effects  because  a  partial  matching  is  not 
an  intrusion.  In  statistical  profile-based  detection  systems, 
if  the  SSO  does  not  think  these  effects  can  cause  any  seri¬ 
ous  damage,  we  can  accept  these  effects;  if  the  SSO  thinks 
these  effects  can  cause  intolerable  damage,  we  can  isolate 
and  move  these  effects  from  the  main  data  version  to  a  sep¬ 
arate  Suspicious  Data  Version ,  which  is  created  to  isolate 
the  user.  The  process  of  isolation  may  need  to  roll  back 
some  trustworthy  actions  that  are  dependent  on  the  suspi¬ 
cious  actions.  At  this  point,  we  can  apply  another  strategy 
that  moves  the  effects  of  these  suspicious  actions  as  well  as 
the  affected  trustworthy  actions  to  the  suspicious  data  ver¬ 
sion. 

Second,  the  Intrusion  Detection  and  Confinement  Man¬ 
ager  notifies  the  Policy  Enforcement  Manager  to  direct  the 
subsequent  suspicious  actions  of  the  user  to  the  separate 
data  version.  Since  we  focus  on  the  isolation  itself,  we  can 
simply  assume  that  when  a  suspicious  behavior  starts  to  be 
isolated,  no  damage  has  been  caused  by  the  behavior.  Note 
that  there  can  be  several  different  suspicious  users,  e.g..  Si, 
...,  Sn,  being  isolated  at  the  same  time.  Therefore,  multi¬ 
ple  suspicious  data  versions  can  exist  at  the  same  time,  and 
these  data  versions  are  usually  different  from  each  other. 


When  a  suspicious  user  turns  out  to  be  malicious ,  that 
is,  his/her  behavior  has  led  to  an  intrusion,  the  correspond¬ 
ing  suspicious  data  version  can  be  discarded  to  protect  the 
main  data  version  from  harm.  On  the  other  hand,  when  the 
user  turns  out  to  be  innocent,  the  corresponding  suspicious 
data  version  is  merged  into  the  main  data  version.  A  sus¬ 
picious  behavior  can  be  malicious  in  several  ways:  (l)  In 
signature-based  detection,  a  complete  matching  can  change 
a  suspicious  behavior  to  malicious.  (2)  Some  statistics  of 
gradual  anomaly,  such  as  frequency  and  total  number,  can 
make  the  SSO  believe  that  a  suspicious  behavior  is  mali¬ 
cious.  (3)  The  SSO  can  find  that  a  suspicious  behavior  is 
malicious  based  on  some  non-technical  evidences. 

A  suspicious  behavior  can  be  innocent  in  several  ways: 
(1)  In  signature-based  detection,  when  no  signatures  can 
be  matched,  the  behavior  proves  innocent.  (2)  The  SSO 
can  prove  it  to  be  innocent  by  some  non-technical  evidence. 
For  example,  the  SSO  can  investigate  the  user  directly.  (3) 
Some  statistics  of  gradual  anomaly  can  also  make  the  SSO 
believe  that  a  behavior  is  innocent. 

Since  intrusion  confinement  cannot  isolate  every  intru¬ 
sion  in  most  cases  (The  rate  of  isolation,  Ri ,  is  usually 
less  than  1),  intrusions  do  happen  on  the  main  data  version. 
When  such  an  intrusion  is  detected  (this  type  of  intrusion 
is  usually  detected  by  some  other  approaches  beyond  the 
standard  mechanisms),  the  corresponding  user  is  marked  as 
malicious .  The  Intrusion  Detection  and  Confinement  Man¬ 
ager  then  notifies  the  Damage  Confinement  and  Assessment 
Manager  to  confine  and  assess  the  damage  caused  by  the 
intrusion.  The  confinement  is  done  by  notifying  the  Policy 
Enforcement  Manager  to  restrict  the  access  by  the  user  by 
either  rejecting  his/her  further  access  or  isolating  the  dam¬ 
age  to  prevent  further  spread.  For  example,  damaged  data 
may  be  forbidden  to  be  read  for  a  while.  Concrete  damage 
confinement  mechanisms  are  out  of  the  scope  of  the  paper. 

After  the  damage  is  assessed,  the  Reconfiguration  Man¬ 
ager  reconfigures  the  system  to  allow  access  to  continue  in 
a  degraded  mode  while  repair  is  being  done  by  the  Dam¬ 
age  Recovery  Manager.  In  many  situations  damage  assess¬ 
ment  and  recovery  are  coupled  with  each  other  closely.  For 
example,  recovery  from  damage  can  occur  during  the  pro¬ 
cess  of  identifying  and  assessing  damage.  Also,  the  sys¬ 
tem  can  be  continuously  reconfigured  to  reject  accesses  to 
newly  identified,  damaged  data  objects  and  to  allow  access 
to  newly  recovered  data  objects.  Interested  readers  can  re¬ 
fer  to  [AJL,  LAJ]  for  more  details  on  damage  confinement, 
damage  assessment,  system  reconfiguration,  and  damage 
recovery  mechanisms  in  the  database  context. 

Intrusion  confinement  mitigates  significantly  the  over¬ 
head  of  damage  confinement,  damage  assessment,  system 
reconfiguration,  and  damage  recovery.  This  is  because  sub- 
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stantial  intrusions  can  be  isolated  before  they  happen;  thus, 
they  will  not  cause  damage  to  the  main  data  version.  How¬ 
ever,  we  need  to  pay  the  extra  cost  of  enforcing  intrusion 
confinement. 

Damage  recovery  may  influence  the  process  of  intrusion 
confinement.  For  example,  if  a  set  of  actions  is  found  to  be 
malicious  and  require  system  recovery,  then  some  actions 
that  are  affected  by  these  malicious  actions  may  have  al¬ 
ready  been  marked  as  suspicious  and  isolated.  At  this  point, 
removing  the  effects  of  these  malicious  actions  from  the 
main  data  version  can  lead  to  removing  the  effects  of  these 
affected  suspicious  actions  from  the  corresponding  suspi¬ 
cious  data  version.  For  simplicity  and  to  focus  on  isolation 
itself,  in  the  rest  of  the  paper  we  assume  that  when  a  sus¬ 
picious  behavior  is  isolated  there  is  no  damage  in  the  main 
data  version. 

4.2  Types  of  Isolation  and  Mergers 

In  the  normal  course  of  events  when  all  users  are  be¬ 
lieved  to  be  trustworthy,  the  data  has  only  one  version, 
namely,  the  main  data  version;  any  updates  by  a  user  are 
seen  by  all  other  users  of  the  database  and  vice  versa.  When 
a  suspicious  user  S*  is  detected,  there  are  several  different 
types  of  data  flow  between  the  trustworthy  actions  working 
on  the  main  data  version  and  the  suspicious  actions  of 

Complete  Isolation  :  Updates  by  Si's  actions  are  not  dis¬ 
closed  to  any  trustworthy  action,  and  any  updates  by  a 
trustworthy  action  are  not  disclosed  to  Si. 

One-way  Isolation  :  Updates  by  Si's  actions  are  not  dis¬ 
closed  to  any  trustworthy  action,  but  all  updates  by  a 
trustworthy  action  are  disclosed  to  5,*.  When  an  up¬ 
date  is  disclosed  to  an  action,  the  action  can  read  the 
updated  value.  By  one-way  isolation.  Si  can  read  the 
latest  value  of  the  data  objects  kept  in  the  main  data 
version. 

Partial  Isolation  :  Some  updates  by  Si's  actions  are  dis¬ 
closed  to  trustworthy  actions,  and  vice  versa.  This  can 
happen  when  Si's  updates  on  some  data  objects  are 
not  considered  risky,  while  anything  else  Si  attempts 
to  update  is  confined  to  the  suspicious  version.  By 
partial  isolation,  if  some  of  the  updates  by  trustwor¬ 
thy  users  are  considered  sensitive,  they  could  be  se¬ 
lectively  withheld  from  being  propagated  to  the  sus¬ 
picious  version  where  they  would  be  divulged  to  the 
suspicious  user.  One  drawback  of  disclosing  Si's  up¬ 
dates  to  trustworthy  users  is  that  after  Si  is  revealed  as 
malicious,  some  trustworthy  actions  affected  by  Si's 
updates  may  have  to  be  backed  out. 


Data  flows  among  suspicious  users  can  also  be  grouped 
into  the  above  three  types.  However,  we  have  not  found 
many  situations  where  it  is  useful  to  disclose  updates  among 
suspicious  versions,  except  when  the  SSO  finds  that  several 
suspicious  users  cooperate  with  each  other  to  do  something. 
At  this  point,  it  is  helpful  that  these  suspicious  users  are 
isolated  within  one  suspicious  version  because  if  they  are 
malicious  users  who  collude  to  do  intrusions  and  to  protect 
themselves  from  being  detected,  then  isolating  each  user 
within  a  separate  version  can  alert  the  user  to  the  fact  that 
something  is  wrong.  If  they  are  innocent  users,  then  iso¬ 
lating  each  user  in  a  separate  version  can  prevent  him/her 
from  inter-communicating.  However,  since  collusions  are 
usually  difficult  to  detect,  and  it  is  usually  a  complicated 
and  computing  intensive  process  to  ensure  the  correctness 
of  such  data  flows.  We  will  not  address  the  problem  in  this 
paper  and  we  would  like  to  address  it  in  our  future  research. 

When  a  user  is  discovered  to  be  malicious  or  innocent,  a 
decision  must  be  made  on  how  to  accept  and  merge  his/her 
updates  into  the  main  data  version.  At  this  point,  two  types 
of  mergers  are  possible: 

Complete  Merger  :  When  a  user  is  discovered  to  be  ma¬ 
licious,  all  of  his/her  updates  are  discarded.  When  a 
user  is  discovered  to  be  innocent,  all  of  his/her  updates 
are  considered  for  merging. 

Partial  Merger  :  Remerging  of  the  data  versions  could  be 
partial.  Even  if  the  user  were  found  to  be  a  malefactor, 
it  might  be  desirable  to  accept  certain  of  his/her  up¬ 
dates  into  the  main  database  version  (for  example,  af¬ 
ter  being  examined,  or  those  on  particular  data  items) 
rather  than  discarding  them  all  outright. 

43  Identification  and  Resolution  of  Conflicts 


Because  suspicious  action  histories  keep  growing,  con¬ 
flicts  may  arise  between  trustworthy  and  suspicious  actions. 
As  a  result,  the  main  data  version  and  these  suspicious  data 
versions  may  become  inconsistent.  For  example,  a  trust¬ 
worthy  action  and  a  suspicious  action  may  update  the  same 
data  object  x ;  thus,  neither  the  main  data  version  of  x  nor 
the  suspicious  data  version  of  x  is  correct  when  we  decide 
to  merge  the  suspicious  version  into  the  main  version. 

The  techniques  to  identify  and  resolve  these  conflicts 
usually  vary  from  one  type  of  system  to  another.  For  ex¬ 
ample,  the  techniques  we  once  proposed  for  database  sys¬ 
tems  in  [JLM98]  are  quite  different  from  the  techniques  we 
will  propose  for  file  systems  in  Section  5.  However,  we  can 
generally  classify  these  techniques  into  two  categories: 
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Static  Resolution  allows  both  the  main  action  history  and 
the  suspicious  action  histories  to  grow  without  any  re¬ 
strictions.  Identification  and  resolution  of  conflicts  are 
delayed  until  some  suspicious  history  is  designated  to 
be  merged  into  the  main  history. 

Dynamic  Resolution  does  not  allow  either  the  main  his¬ 
tory  or  the  suspicious  histories  to  grow  unless  the  mu¬ 
tual  consistency  is  guaranteed. 

4.4  Requirements  for  an  Isolation  System 

An  isolation  system  should  satisfy  several  general  re¬ 
quirements  to  ensure  the  security  and  correctness  of  intru¬ 
sion  confinement. 

Disclosure  Property  :  The  isolation  strategy  should  never 
cause  risky  data  flows  from  suspicious  data  versions  to 
the  main  data  version. 

Consistency  Property  :  Before  and  after  each  merger,  the 
main  data  version  and  the  suspicious  data  versions 
should  be  kept  consistent.  The  consistency  of  the  main 
version  can  be  relaxed  when  some  suspicious  updates 
are  disclosed  to  it.  The  consistency  of  a  suspicious  ver¬ 
sion  can  be  relaxed  when  some  trustworthy  updates  are 
disclosed  to  it. 

Synchronization  Property  :  A  suspicious  data  version 
cannot  be  merged  into  the  main  data  version  if  it  is  still 
dependent  on  some  other  suspicious  data  versions. 

5  Intrusion  Confinement  in  File  Systems 

In  this  section,  we  will  present  a  concrete  isolation  pro¬ 
tocol  in  the  file  system  context  to  evaluate  the  feasibility  of 
our  general  intrusion  confinement  solution. 

5.1  Isolation  Protocol 

Consider  a  file  system  with  a  set  of  files,  denoted  /i, 
/n,  that  are  accessed  by  users.  These  files  can  be  of 
many  types,  such  as  normal  files,  directories,  and  devices.  A 
user  can  access  a  file  in  many  ways,  such  as  reading,  writ¬ 
ing,  modifying,  renaming,  deleting,  copying,  and  moving. 
In  this  section,  we  choose  one-way  isolation  as  the  isolation 
strategy  and  complete  merger  as  the  merging  strategy,  and 
forbid  data  flows  among  suspicious  versions. 

The  isolation  protocol  which  is  specified  as  follows  is 
adapted  from  [PPR+83],  where  a  protocol  is  proposed  to 


detect  and  resolve  mutual  inconsistency  in  distributed  file 
systems.  In  this  protocol,  the  isolation  is  processed  in  terms 
of  each  file.  When  a  file  fi  is  modified  by  a  suspicious 
user  Si ,  the  modification  and  the  possible  following  modi¬ 
fications  of  Si  on  fi  will  be  isolated  until  Si  proves  to  be 
malicious  or  innocent.  To  identify  the  conflicts  between  the 
modifications  of  Si  on  fi  and  the  modifications  of  trustwor¬ 
thy  users  on  /*,  we  associate  a  version  vector  with  the  main 
version  of  fi  and  a  version  vector  with  every  isolated  ver¬ 
sion  of  fi.  Note  that  if  a  file  has  never  been  modified  by  a 
suspicious  user,  then  it  has  no  version  vectors. 

•  Each  file  fi  is  associated  with  a  system-wide,  unique 
identifier,  called  origin  point  (denoted  OP(/i)),  which 
is  generated  when  fi  is  created.  It  is  an  immutable 
attribute  of  fi ,  although  fi  s  name  is  not  immutable 
(indeed,  fi  may  have  different  names  in  different  ver¬ 
sions).  Thus,  no  number  of  modifications  or  renamings 
of  fi  will  change  OP(fi). 

•  At  the  very  beginning  when  there  are  no  suspicious 
users,  the  version  vector  of  the  main  version  of  a  file 
fi  can  be  viewed  as  <  G  :  0  >,  although  we  do  not 
maintain  such  a  vector  until  fi  is  updated  by  a  suspi¬ 
cious  user.  Here,  G  denotes  the  main  version. 

•  When  a  file  fi  is  firstly  modified  by  a  suspicious  user 
(denoted  Si),  an  isolated  version  of  fi  (with  the  same 
OP(fi )),  called  the  Si -version  of  /{,  is  created  for  Si 
to  perform  the  modification.  As  a  result,  two  different 
versions  of  fi  exist  after  the  modification:  one  is  the 
main  version,  with  no  effects  of  the  modification  on  it; 
the  other  is  the  Si -version  on  which  the  modification 
is  performed.  We  generate  the  corresponding  version 
vectors  as  follows:  (1)  for  the  main  version,  <  G  : 
0,Si  :  0  >  is  created  as  the  version  vector.  Si  :  0 
signifies  that  the  version  has  not  been  modified  by  Si. 
G  :  0  signifies  that  the  version  has  not  been  modified 
by  trustworthy  users  since  fi  is  firstly  modified  by  a 
suspicious  user  (here  the  user  is  Si).  (2)  for  the  Si- 
version,  <  G  :  0,  Si  :  m  >  is  created  as  the  version 
vector.  The  G  dimension  ( G  :  0)  is  copied  from  the 
main  version  vector.  Si  :  m  means  that  fi  has  been 
modified  by  Si.  Note  that  m  is  not  a  number.  The  Si 
dimension  remains  to  be  m  no  matter  how  many  times 
the  Si -version  is  modified. 

•  The  version  vector  of  the  main  version  of  a  file  /*,  if  it 
exists,  is  changed  by  modifications  performed  by  trust¬ 
worthy  users  as  follows:  (1)  after  each  such  modifica¬ 
tion,  its  value  in  the  G  dimension  is  increased  by  1, 
i.e.,  from  G  :  n  to  G  :  n  +  1.  (2)  the  value  in  any  other 
dimension  is  unchanged. 
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•  When  a  suspicious  user  Si  asks  to  modify  a  file  /*  (we 
assume  /*  has  already  been  modified  by  some  suspi¬ 
cious  users),  if  an  Si-version  of  ft  exists,  then  the  ver¬ 
sion  is  given.  Otherwise,  if  there  is  neither  active  nor 
deleted  Si-versions,  then  we  first  insert  into  the  main 
version  vector  of  f\  the  Si  dimension  with  the  value 
Si  :  0,  then  create  the  Si-version  of  fi  on  which  Si 
performs  the  modification.  The  Si-version  vector  is 
created  by  first  copying  the  main  version  vector  and 
then  changing  its  value  in  the  Si  dimension  to  Si  :  m. 
As  before,  additional  modifications  of  Si  on  fi  do  not 
change  the  Si-version  vector. 

•  When  a  suspicious  user  Si  asks  to  delete  a  file  /i,  if 
there  is  an  Si-version  of  fi  that  has  not  been  deleted, 
then  (1)  the  Si -version  is  deleted;  (2)  the  value  of  the 
Si-version  vector  in  the  Si  dimension  is  changed  to 
Si  :  d ,  which  indicates  that  the  Si-version  of  fi  is  re¬ 
moved.  However,  the  origin  point  OP(fi)  associated 
with  the  Si-version  vector  of  fi  remains.  Otherwise,  if 
there  is  neither  active  nor  deleted  Si-versions,  then  the 
Si  dimension  with  the  value  Si  :  0  is  inserted  into  the 
main  version  vector  of  /i,  and  the  Si -version  vector  of 
fi  is  created  by  first  copying  the  main  version  vector 
of  fi  and  then  changing  its  value  in  the  Si  dimension 
to  Si  :  d. 

•  When  a  trustworthy  user  asks  to  delete  a  file  /*,  if  the 
main  version  exists,  then  the  G  dimension  of  the  main 
version  vector  of  fi  (if  any)  is  changed  to  G  :  d,  and 
the  main  version  of  fi  will  be  removed.  However,  the 
origin  point  OP(fi)  associated  with  the  main  version 
vector  of  fi  remains.  We  keep  the  vector  because  at 
this  time  some  suspicious  versions  of  fi  could  still  ex¬ 
ist. 

•  When  a  suspicious  user  Si  asks  to  access  a  file  fi  and 
the  value  of  the  Si-version  vector  in  the  Si  dimension 
is  dy  then  the  system  notifies  Si  that  f  does  not  exist. 
When  a  trustworthy  user  asks  to  access  fi  and  the  value 
of  the  main  vector  in  the  G  dimension  is  d ,  then  the 
system  notifies  the  user  that  fi  does  not  exist. 

•  When  a  suspicious  Si  asks  to  read  a  file  /{,  if  there 
is  a  Si- version  of  /i,  then  the  version  is  given  to  Si. 
Otherwise,  if  the  main  version  of  fi  exists,  then  the 
main  version  is  given. 

•  When  a  suspicious  version  is  merged  with  the  main 
version,  the  main  version  vector  of  fi  can  have  more 
dimensions  than  the  suspicious  version  vector  of  /*. 
To  identify  and  resolve  the  conflicts  between  these  two 
versions,  we  need  to  first  pad  the  suspicious  version 
vector  such  that  the  two  vectors  have  the  same  set  of 
dimensions.  The  padding  is  done  by  inserting  each 


missed  dimension  with  the  value  0  into  the  suspicious 
version  vector.  The  techniques  used  to  identify  and  re¬ 
solve  the  conflicts  are  presented  in  next  section. 

5.2  Identification  and  Resolution  of  Conflicts 

There  are  two  types  of  conflicts  that  we  wish  to  consider: 
name  conflicts  and  version  conflicts .  A  name  conflict  occurs 
when  two  files  with  different  origin  points  have  the  same 
name.  In  contrast,  a  version  conflict  occurs  when  two  ver¬ 
sions  of  the  same  file  (the  same  origin  point)  have  been  in¬ 
compatibly  modified.  For  example,  two  versions  of  a  file 
generated  by  independent  modifications  of  an  older  version 
of  the  file  can  introduce  a  version  conflict.  Two  versions  of 
a  file  are  compatible  iff  there  is  no  version  conflict  between 
them. 

When  a  suspicious  data  version  is  merged  into  the  main 
data  version,  we  identify  the  version  conflicts  on  a  file  fi  as 
follows: 

•  If  both  the  suspicious  version  of  fi  and  the  main  ver¬ 
sion  of  fi  are  deleted,  or  at  least  one  of  them  is  deleted, 
then  they  are  compatible. 

•  If  none  of  them  are  deleted,  then  the  two  versions  are 
compatible  if  their  corresponding  version  vectors  are 
compatible.  Two  version  vectors  are  compatible  if  one 
vector  Vi  dominates  the  other  vector  v]  in  the  value  of 
every  dimension.  If  so,  we  say  vl  dominates  Vj .  In 
our  model,  value  domination  is  defined  as  follows:  (1) 
A  value  dominates  itself.  (2)  A  number  n\  dominates 
another  number  n 2  if  ni  is  larger  than  n 2.  (3)  The 
value  m  (in  Si  :  m)  dominates  the  value  0.  (4)  The 
value  d  is  dominated  by  any  other  values. 

Name  conflicts  can  be  easily  resolved  by  renaming  files 
after  all  of  the  version  conflicts  are  resolved.  Resolution 
of  version  conflicts  should  be  accompanied  by  resolution  of 
version  vector  conflicts  because  we  cannot  merge  two  ver¬ 
sions  without  merging  their  version  vectors.  When  the  con¬ 
flicts  between  a  suspicious  Si-version  (with  version  vector 
v*s)  and  a  main  data  version  (with  version  vector  of  a 
file  fi  are  identified,  we  resolve  the  conflicts  and  merge  the 
two  versions  as  follows.  The  protocol  can  ensure  that  in  the 
merged  vector:  (1)  G  :  d  indicates  the  merged  version  is 
removed;  otherwise,  it  exists.  (2)Si  :  0  indicates  there  is  (or 
was)  a  suspicious  Si -version.  The  version  may  still  be  ac¬ 
tive  or  may  have  already  been  discarded.  (3)Si :  d  indicates 
there  was  a  suspicious  Si-version  that  has  been  deleted  by 
Sj,  who  is  innocent.  (4)Si  :  m  indicates  there  was  a  sus¬ 
picious  Si -version.  The  version  is  modified  by  Si  and  is 
merged. 
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•  If  both  of  the  two  versions  are  deleted,  then  they  need 
not  be  merged;  however,  their  version  vectors  need  be 
merged.  The  merging  is  done  by  taking  v*g  with  its 
value  in  the  Si  dimension  changed  to  Si  :  d  as  the 
merged  vector. 

•  Suppose  that  the  main  version  is  deleted,  but  the  Si - 
version  is  not  deleted.  If  the  value  of  ifs  in  the  Si  di¬ 
mension  is  m,  then  the  Si  version  is  the  merged  ver¬ 
sion,  and  the  merged  vector  is  Vg  with  its  value  in  the  G 
dimension  changed  to  that  of  xTs  and  its  value  in  the  Si 
dimension  changed  to  m.  Otherwise,  the  deleted  main 
version  is  the  merged  version,  and  the  merged  vector 
is  V 

•  Suppose  that  the  S^-version  is  deleted,  but  the  main 
version  is  not  deleted.  If  the  value  of  v*g  in  the  G  di¬ 
mension  is  larger  than  that  of  v*s,  or  there  is  a  dimen¬ 
sion  such  that  the  value  of  v*g  in  the  dimension  is  m 
but  the  value  of  vs  in  the  dimension  is  0  or  v*s  does 
not  include  the  dimension,  then  the  main  version  is  the 
merged  version,  and  vg  with  its  value  in  the  Si  dimen¬ 
sion  changed  to  Si  :  d  is  the  merged  vector.  Otherwise, 
the  deleted  Si  version  is  the  merged  version,  and  v*g 
with  its  value  in  the  G  dimension  changed  to  d  and  its 
value  in  the  Si  dimension  changed  to  d  is  the  merged 
vector. 

•  If  none  of  the  two  versions  are  deleted: 

-  If  vg  dominates  vs,  then  the  main  version  is  the 
resolved  version.  vg  is  the  merged  vector. 

-  If  vs  dominates  Vg ,  then  the  suspicious  version  is 
the  resolved  version.  vs  is  the  merged  vector. 

-  If  Vg  and  v*s  are  incompatible,  then  the  resolu¬ 
tion  can  be  done  either  manually  or  automati¬ 
cally,  based  on  the  semantics  of  the  modifications 
that  have  been  applied  on  these  versions.  After 
the  resolution,  Vg  with  its  value  in  the  Si  dimen¬ 
sion  changed  to  m  is  the  merged  vector.  Note 
that  here  a  version  conflict  can  happen  only  if  the 
value  of  v*$  in  the  Si  dimension  is  m. 

Example  2  Assume  that  when  the  52 -version  is  merged 
into  the  main  version,  the  main  version  vector  of  a  file  fi  is: 
v*9(fi)  =<  G  :  0,  Si  :  0,52  :  0  >.  At  this  point,  if  the  5 2- 
version  vector  off  is  v*s(fi)  =<  G  :  0,  5i  :  0, 52  :  m  >, 
then  since  v*s(fi )  dominates  v*g(fi),  so  there  are  no  con¬ 
flicts,  and  the  52 -version  is  the  merged  version,  and  v*s(fi) 
is  the  merged  vector  Ifv*s(fi )  =<  G  :  0,  S\  :  0, 52  :  d  >, 
then  the  two  versions  are  still  compatible .  The  deleted  52- 
version  is  the  merged  version,  and  <  G  :  d,S\  :  0, 52  :  d  > 
is  the  merged  vector. 


Consider  another  scenario  where  v*9(fi)  ~<  G  :  2,5i  : 
0, 5>  :  0  >  and  Vs{fi)  =  <  G  :  0,5i  :  0,52  :  m  >. 
v*9(fi)  and  Vs  (fi)  conflict.  Note  that  the  version  of  fi  with 
the  vector  <  G  :  0, 5i  :0,52  :0>  has  been  independently 
modified  by  5>  and  some  trustworthy  transactions.  At  this 
point,  manual  or  automatic  approaches  need  be  applied  to 
resolve  the  conflicts.  The  version  vector  of  the  resolved  ver¬ 
sion  is  <  G  :  2,  Si  :  0,  So  :  m  >. 

To  reduce  the  overhead  of  maintaining  version  vectors, 
we  need  to  reset  main  version  vectors.  The  reset  for  the 
main  version  vector  of  fi  can  be  processed  when  there  are 
no  active  accesses  to  fi  and  when  fi  has  not  been  modified 
or  deleted  in  any  active  suspicious  versions.  The  reset  can 
be  easily  done  by  removing  the  main  version  vector. 

Although  there  is  no  general  way  to  resolve  conflicts  au¬ 
tomatically,  conflict  resolution  can  be  automated  in  many 
file  systems  by  exploiting  the  operation  semantics.  For  ex¬ 
ample,  reconciliation  for  two  important  types  of  files  in  LO¬ 
CUS  [PPR+83],  directories  and  user  mailboxes,  is  handled 
automatically.  Interested  readers  can  refer  to  [PPR+83]  for 
more  details  on  this  topic. 

6  Related  Work 

A  substantial  body  of  work  has  been  done  on  intrusion 
detection  [Lun93,  MHL94,  LM98],  based  on  either  detect¬ 
ing  deviations  from  expected  statistical  profiles  [JV94]  or 
pattern-matching  against  known  methods  of  attack  [Ilg93, 
GL91,  PK92,  IKP95,  SG91,  SG97,  LWJ98].  In  [JV94],  the 
idea  of  setting  multiple  alert  levels  is  proposed,  where  each 
alert  level  corresponds  to  a  specific  degree  of  anomaly  and 
different  actions  are  taken  at  each  alert  level.  However,  the 
issues  of  what  actions  should  be  taken  at  each  level  and  how 
to  enforce  these  actions  are  not  addressed  in  [JV94].  Our 
isolation  scheme  can  be  viewed  as  a  realization  of  the  idea 
in  which  two  alert  levels  are  set.  At  the  first  alert  level,  we 
isolate  users’  accesses  when  a  suspicious  behavior  is  dis¬ 
covered.  At  the  second  alert  level,  we  reject  users’  accesses 
when  an  intrusion  is  reported.  Multi-level  isolation  schemes 
are  certainly  possible. 

In  [LV92]  and  [HLR92],  a  probabilistic  model  of  intru¬ 
sion  detection  is  proposed  in  which  intrusion  detection  is 
characterized  as  an  estimation  problem.  In  the  model,  the 
probability  that  a  behavior  is  a  signature-based  is  measured 
by  modeling  computer  activity  as  a  finite  stationary  stochas¬ 
tic  process.  In  our  probabilistic  model,  Pi  (or  Re)  can  be 
measured  by  their  model;  however,  the  rate  of  detection 
( Rd )  is  not  addressed  in  their  model. 

In  [JLM98],  an  application-level  isolation  protocol  is 
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proposed  to  cope  with  malicious  database  users.  In  this 
paper,  we  extend  the  work  of  [JLM98]  in  several  aspects: 
(1)  [JLM98]  does  not  answer  clearly  the  questions  such  as 
“why  are  there  suspicious  actions,”  “how  can  these  suspi¬ 
cious  actions  be  detected,”  “why  is  isolation  necessary”  and 
“when  should  isolation  be  enforced  ”  In  this  paper,  we  give 
clear  answers  to  these  questions  by  proposing,  modeling, 
and  analyzing  the  problem  of  intrusion  confinement  based 
on  a  probabilistic  model  presented  to  evaluate  the  effective¬ 
ness  of  current  intrusion  detection  systems.  (2)  [JLM98]  is 
limited  to  the  database  context.  In  this  paper,  we  extend 
the  isolation  mechanisms  proposed  in  [JLM98]  to  a  general 
solution  that  can  be  applied  in  many  types  of  information 
systems,  such  as  file  systems  and  object  systems.  (3)  We 
present  a  novel  isolation  protocol  for  file  systems  that  is  not 
addressed  by  [JLM98]. 

Although  the  area  of  IW  defense  is  new,  some  relevant 
work  exists.  Graubart  et  al.  [GSM96]  identify  a  number 
of  aspects  of  the  management  of  a  DBMS  that  affect  vul¬ 
nerability  with  respect  to  IW.  McDermott  and  Goldschlag 
[MG96a,  MG96b]  identify  some  techniques  for  defending 
against  data  jamming  that,  while  primarily  intended  for  de¬ 
tection,  could  also  help  deceive  the  attacker  and  confuse  the 
issue  of  which  data  values  are  critical. 

Finally,  Ammann  et  al.  [AJMB97]  take  a  detailed  look 
at  the  problem  of  surviving  IW  attacks  on  databases.  They 
identify  a  number  of  phases  of  the  IW  process  and  describe 
activities  that  occur  in  each  of  them.  To  maintain  precise 
information  about  the  attack,  they  propose  to  mark  data  to 
reflect  the  severity  of  detected  damage  as  well  as  the  degree 
to  which  the  damaged  data  has  been  repaired.  They  define 
an  access  protocol  for  normal  transactions  and  show  that 
transactions  following  the  protocol  will  maintain  database 
consistency  even  if  part  of  the  database  is  damaged. 

7  Conclusion 

In  this  paper,  we  proposed,  modeled,  and  analyzed  the 
problem  of  intrusion  confinement.  It  is  shown  that  intrusion 
confinement  can  effectively  resolve  the  conflicting  design 
goals  of  an  intrusion  detection  system  by  achieving  both  a 
high  rate  of  detection  and  a  low  rate  of  errors.  It  is  also 
shown  that  as  a  second  level  of  protection  in  addition  to 
access  control  intrusion  confinement  can  dramatically  en¬ 
hance  the  security  (especially  integrity  and  availability)  of 
a  system  in  many  situations. 

We  proposed  a  general  solution  that  is  based  on  a  spe¬ 
cific  isolation  mechanism  to  achieve  intrusion  confinement. 
We  evaluated  the  feasibility  of  the  solution  by  presenting  a 
concrete  isolation  scheme  that  can  be  enforced  in  the  file 


system  context.  It  is  shown  that  this  protocol  is  more  flex¬ 
ible,  economical,  and  efficient  than  fishbowling,  and  it  can 
be  applied  to  every  file  system.  Finally,  we  would  mention 
that  the  general  intrusion  confinement  solution  can  be  ap¬ 
plied  to  many  other  types  of  information  systems  in  addition 
to  file  systems,  such  as  database  systems  (a  simple  isolation 
scheme  is  proposed  in  [JLM98]),  object-oriented  systems, 
distributed  information  systems,  and  workflow  management 
systems.  Developing  concrete  isolation  protocols  for  these 
systems  is  a  topic  of  our  future  research. 
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Abstract 

\ 

This  paper  presents  an  analysis  of  a  simple  equal¬ 
ity  matching  algorithm  that  detects  intrusions  against 
systems  by  profiling  the  behavior  of  programs.  The 
premise  for  this  work  is  that  abnormally  behaving  pro¬ 
grams  are  a  primary  indicator  of  computer  intrusions. 
Program  behavior  profiles  are  built  by  capturing  sys¬ 
tem  calls  made  by  the  target  program  under  normal 
operational  conditions  using  Sun  Microsystem’s  Ba¬ 
sic  Security  Module  (BSM)  auditing  facility.  Poten¬ 
tial  intrusions  are  flagged  when  a  significant  portion 
of  BSM  events  in  a  given  interval  are  determined  to 
be  anomalous.  This  approach  exploits  the  temporal  lo¬ 
cality  of  anomalies  induced  by  attacks  to  reduce  the 
false  alarm  rate  caused  by  anomalous  noise  as  well  as 
detect  intrusions  that  might  otherwise  be  washed  out 
in  the  anomalous  noise.  The  analysis  uses  data  col¬ 
lected  by  the  Air  Force  Research  Laboratory  and  pro¬ 
vided  by  the  MIT  Lincoln  Laboratory  under  the  1998 
DARPA  Intrusion  Detection  Evaluation  program.  At¬ 
tack  sessions  are  embedded  in  normal  background  traf¬ 
fic  so  that  the  analysis  can  measure  the  probability  of 
detection  simultaneously  with  the  probability  of  false 
alarm.  The  analysis  uses  Receiver  Operator  Charac¬ 
teristic  (ROC)  curves  to  show  the  performance  of  the 
system  in  terms  of  the  probability  of  false  alarm  and 
probability  of  detection  for  different  operating  points. 
These  results ,  can  in  turn,  be  used  to  tune  the  system 
to  meet  a  particular  network’s  requirements  on  detec¬ 
tion  and  false  alarm  rates . 


•This  work  is  sponsored  under  Defense  Advanced  Research 
Projects  Agency  (DARPA)  Contract  DAAH01-98-C-R145.  the 
VIEWS  AND  CONCLUSIONS  CONTAINED  IN  THIS  DOCUMENT  ARE 
THOSE  OF  THE  AUTHORS  AND  SHOULD  NOT  BE  INTERPRETED 
AS  REPRESENTING  THE  OFFICIAL  POLICIES,  EITHER  EXPRESSED 
OR  IMPLIED,  OF  THE  DEFENSE  ADVANCED  RESEARCH  PROJECTS 
AGENCY  OR  THE  U.S.  GOVERNMENT. 


1  Introduction 

Intrusion  detection  generally  can  be  defined  as  a 
method  to  detect  any  unauthorized  use  of  a  system. 
Intrusions  are  commonly  considered  to  be  attacks  from 
unauthorized  outside  entities  to  gain  access  to  a  tar¬ 
get  system.  Once  inside,  an  intruder  can  illegally  use 
resources,  view  confidential  material,  or  even  try  to 
subvert  or  harm  the  system.  The  term  is  less  com¬ 
monly  used,  yet  equally  applicable,  to  describe  attacks 
from  within  the  target  system  by  authorized  insiders 
who  attempt  to  abuse  their  privileges  or  acquire  higher 
privileges  in  violation  of  security  policies. 

Intrusion  detection  techniques  are  generally  clas¬ 
sified  into  one  of  two  approaches:  misuse  detection 
and  anomaly  detection.  Misuse  detection  methods  at¬ 
tempt  to  model  attacks  on  a  system  as  specific  pat¬ 
terns,  then  systematically  scan  the  system  for  oc¬ 
currences  of  these  patterns  [Garvey  and  Lunt,  1991, 
Hgun,  1992,  Lunt,  1993,  Kumar  and  Spafford,  1996, 
Porras  and  Kemmerer,  1992].  This  process  involves 
a  specific  encoding  of  previous  behaviors  and  actions 
that  were  deemed  intrusive  or  malicious.  Anomaly  de¬ 
tection  assumes  that  intrusions  axe  highly  correlated 
to  abnormal  behavior  exhibited  by  either  a  user  or 
network  traffic.  The  basic  idea  of  anomaly  detection 
is  to  baseline  the  normal  behavior  of  the  object  be¬ 
ing  monitored  and  then  flag  behaviors  that  are  sig¬ 
nificantly  different  from  this  baseline  as  abnormal¬ 
ities,  or  possible  intrusions  [D’haeseleer  et  ah,  1996, 
Lunt,  1993,  Lunt  and  Jagannathan,  1988,  Lunt,  1990, 
Lunt  et  al.,  1992,  Monrose  and  Rubin,  1997]. 

The  most  significant  disadvantage  of  misuse  detec¬ 
tion  approaches  is  that  they  will  only  detect  the  at¬ 
tacks  that  they  are  trained  to  detect.  Novel  attacks  or 
even  variants  of  common  attacks  often  go  undetected. 
In  a  time  when  new  security  vulnerabilities  in  soft¬ 
ware  are  discovered  and  exploited  every  day,  the  reac- 
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tive  approach  embodied  by  misuse  detection  methods 
is  not  feasible  for  defending  systems. 

The  main  advantage  of  anomaly  detection  ap¬ 
proaches  is  the  ability  to  detect  novel  attacks,  variants 
of  known  attacks,  and  deviations  from  normal  usage 
of  programs  regardless  of  whether  the  source  is  a  priv¬ 
ileged  internal  user  or  an  unauthorized  external  user. 
One  drawback  of  anomaly  detection  approaches  is  that 
well-known  attacks  may  not  be  detected,  particularly 
if  they  fit  the  established  profile  of  the  user.  Once  de¬ 
tected,  it  is  often  difficult  to  characterize  the  nature 
of  the  attack  for  forensic  purposes.  Another  drawback 
of  many  anomaly  detection  approaches  is  that  a  ma¬ 
licious  user  who  knows  he  or  she  is  being  profiled  can 
change  his  or  her  profile  slowly  over  time  to  essentially 
train  the  anomaly  detection  method  to  learn  his  or 
her  malicious  behavior  as  normal.  Finally,  a  narrowly 
trained  detection  algorithm  may  result  in  a  high  false 
positive  rate,  or  conversely,  a  broadly  trained  anomaly 
detection  approach  may  result  in  a  high  false  negative 
rate. 

Desiring  the  ability  to  detect  novel,  unknown  at¬ 
tacks  against  systems,  an  anomaly  detection  approach 
is  employed  in  this  research.  Unlike  traditional 
anomaly  detection  approaches,  this  research  applies 
anomaly  detection  at  the  system  process  level.  Rather 
than  profiling  the  normal  behavior  of  users,  the  ap¬ 
proach  here  is  to  profile  the  normal  behavior  of  exe¬ 
cuting  processes.  Monitoring  at  the  process  level  ab¬ 
stracts  away  users’  idiosyncrasies  such  that  abnormal 
process  behavior  can  be  detected  irrespective  of  indi¬ 
vidual  users’  behavior.  Having  baselined  the  normal 
behavior  of  a  process,  deviations  from  the  normal  be¬ 
havior  can  be  used  to  detect  attempted  exploitations 
of  the  program.  A  corollary  of  this  approach  is  that 
attempted  misusage  of  programs  that  does  not  alter 
normal  program  behavior  is  not  flagged. 

2  Prior  art 

While  intrusion  detection,  and  anomaly  detection 
approaches  in  particular,  have  been  the  focus  of  much 
recent  research,  the  work  of  two  groups  out  of  the 
University  of  New  Mexico  and  Columbia  University  is 
most  closely  related  to  ours  and  has  been  leveraged 
for  the  purposes  of  our  research. 

The  work  of  Forrest  et  al.  from  the  University  of 
New  Mexico  has  firmly  established  the  analogy  be¬ 
tween  the  human  immune  system  and  intrusion  de¬ 
tection  [Forrest  et  al.,  1997,  D’haeseleer  et  al.,  1996, 
Forrest  et  al.,  1996].  The  UNM  work  was  among  the 
first  to  focus  intrusion  detection  at  the  system  pro¬ 
cess  level  (in  addition,  see  [Voas  et  al.,  1992]).  The 
UNM  group  used  short  sequences  of  system  calls  from 


the  target  program  to  the  operating  system  to  form 
a  signature  for  normal  behavior.  A  database  of  sys¬ 
tem  calls  is  built  from  executing  a  program  under  nor¬ 
mal  usage  conditions  and  capturing  all  system  calls 
made  by  the  program.  Once  constructed,  the  database 
essentially  serves  as  the  repository  for  self  behavior 
against  which  all  subsequent  online  behavior  will  be 
judged.  If  a  string  formed  during  the  online  operation 
of  the  program  does  not  match  a  string  in  the  nor¬ 
mal  database,  a  mismatch  is  recorded.  If  the  number 
of  mismatches  detected  is  a  significant  percentage  of 
all  strings  captured  during  the  online  session,  then  an 
intrusion  is  registered.  This  approach  has  the  draw¬ 
back  that  anomalous  events  are  averaged  out  over  the 
entire  execution  trace,  which  could  result  in  attacks 
being  washed  out  in  anomalous  noise  (see  Section  4). 

The  work  of  the  Columbia  group  applied  a  rule- 
based  expert  system  for  detecting  intrusions  to  the 
data  collected  by  the  UNM  group  [Lee  et  al.,  1997]. 
The  approach  applied  a  rule  learning  program,  RIP¬ 
PER  [Cohen,  1995],  to  the  data  to  extract  rules  for 
predicting  whether  a  sequence  of  system  calls  is  nor¬ 
mal  or  abnormal.  Because  the  rules  made  by  RIP¬ 
PER  can  be  erroneous,  a  post-processing  algorithm 
is  used  to  scan  the  predictions  made  by  RIPPER  to 
determine  if  an  intrusion  has  occurred  or  not.  The 
post-processing  algorithm  uses  the  notion  of  temporal 
locality  to  filter  spurious  prediction  errors  from  intru¬ 
sions  which  should  leave  temporally  co-located  abnor¬ 
mal  predictions.  This  notion  of  temporal  locality  of 
abnormal  traces  is  used  in  our  work  as  described  in 
Section  4.  That  is,  rather  than  averaging  the  number 
of  abnormal  system  calls  out  of  the  total  number  of 
system  calls  made  (a  la  UNM  work),  a  number  of  ab¬ 
normal  local  regions  (consisting  of  windows  of  system 
calls)  is  used  to  determine  if  an  intrusion  has  occurred. 

One  drawback  of  rule-based  approaches  is  that 
it  is  difficult  to  encode  a  specific  sequence  of  ac¬ 
tions  efficiently  because  clauses  in  the  if-then  rules 
are  inherently  unordered.  Thus,  most  rules  will 
fire  due  to  an  arbitrary  permutation  of  its  clauses 
[Kumar  and  Spafford,  1996].  RIPPER  only  outputs 
rules  for  the  “minority”  class.  Thus,  if  the  training 
data  has  fewer  abnormal  sequences  than  normal  ones, 
then  the  RIPPER  rules  become  a  technique  for  de¬ 
tecting  known  intrusions  (viz.,  misuse  intrusion  detec¬ 
tion).  Conversely,  if  normal  behavior  forms  the  minor¬ 
ity  class,  then  RIPPER  rules  can  be  used  for  anomaly 
detection.  The  results  in  [Lee  et  al.,  1997]  show  the 
ability  to  use  RIPPER  for  either  anomaly  detection 
or  misuse  detection. 
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3  Building  program  behavior  profiles 

The  data  collected  for  building  program  behavior 
profiles  is  the  set  of  BSM  events  made  by  the  programs 
under  analysis  and  recorded  by  Sun  Microsystem’s  Ba¬ 
sic  Security  Module  (BSM)  system  auditing  facility  for 
Solaris.  The  data  was  collected  over  a  period  of  weeks 
in  a  controlled  environment  on  an  internal  Air  Force 
Research  Laboratory  (AFRL)  network  and  provided 
to  us  by  MIT’s  Lincoln  Laboratory  under  the  DARPA 
1998  Intrusion  Detection  Evaluation  program1.  At¬ 
tack  sessions  are  embedded  within  normal  background 
traffic  sessions,  which  allows  us  to  measure  both  cor¬ 
rect  detection  and  false  alarm  rates  simultaneously. 
In  addition  to  BSM  data,  TCP/IP  connections  were 
provided  through  the  tcpdump  network  packet  sniffer 
facility.  This  data  was  not  used  in  this  study  as  we 
are  attempting  to  use  only  program  behavior  profiles 
to  detect  intrusions  against  these  programs.  The  re¬ 
search  described  in  [Forrest  et  al.,  1997]  indicates  that 
short  sequences  of  system  calls  provide  a  compact  and 
adequate  “signature  of  self”  that  can  be  used  to  distin¬ 
guish  between  normal  (“self”)  behavior  and  abnormal 
(dangerous  “non-self”)  behavior.  The  conclusions  in 
[Forrest  et  al.,  1997]  show  that  the  data  is  still  too  in¬ 
conclusive  to  determine  if  equality  matching  of  system 
calls  is  a  viable  approach  to  intrusion  detection.  The 
detailed  analyses  performed  in  this  paper  in  a  con¬ 
trolled,  scientific  study  coordinated  with  MIT’s  Lin¬ 
coln  Laboratory  demonstrate  the  viability  of  this  ap¬ 
proach  when  extended  to  exploit  temporal  locality. 

The  session  data  provided  by  Lincoln  Laboratory 
was  labeled  for  training  purposes  such  that  intrusive 
sessions  can  be  distinguished  from  normal  sessions. 
Using  these  session  labels,  the  intrusion  sessions  are 
separated  from  normal  sessions.  Because  our  approach 
is  based  on  anomaly  detection,  we  use  only  the  nor¬ 
mal  sessions  for  training.  A  database  is  constructed 
for  each  program.  The  database  is  simply  a  table  that 
consists  of  every  unique  iV-gram  of  BSM  events  that 
occurred  during  any  execution,  as  well  as  a  frequency 
count  for  each  iV-gram.  An  iV-gram  is  a  sequence  of 
N  events.  For  instance,  given  the  following  snippet 
from  a  pre-processed  file  of  BSM  events  (where  single 
letters  represent  events), 

[pid  1]  A; [pid  1]  B;  [pid  2]  C; [pid  1]  D; 

[pid  1]  B;  [pid  2]  A;  [pid  1]  D;[pid  1]  B; 

[pid  2]  E; [pid  2]  B; [pid  2]  D; , 

and  given  an  AT-gram  size  of  two,  a  table  of  all  ob¬ 
served  iV-grams  could  be  constructed.  First,  the 

1See  ww.ll.mit .edu/IST/ideval/index.html  for  a  sum¬ 
mary  of  the  program. 


two  processes  represented  in  the  file  must  be  de- 
interleaved,  producing  the  following  execution  traces: 

pid  1:  A  B  D  B  D  B 
pid  2:  C  A  E  B  D. 

A  sliding  window  with  a  size  of  two  (as  specified  above) 
would  be  passed  over  the  execution  trace  of  the  first 
process,  to  collect  all  iV-grams  with  a  size  of  two.  As 
a  result,  the  following  table  would  be  created.  The 


BSM  iV-grams 

Frequency 

A  B 

1 

B  D 

2 

D  B 

2 

Table  1:  Table  of  normal  behavior  profile  for  the 
first  process  for  an  AT-gram  size  of  two.  Total 
number  of  unique  iV-grams  is  three,  and  the 
total  number  of  iV-grams  is  five. 

same  process  is  applied  to  the  execution  trace  of  the 
second  process,  and  the  results  are  added  to  the  same 
table  to  produce  table  2. 


BSM  Ar-grams 

Frequency 

AB 

i 

B  D 

3 

D  B 

2 

C  A 

1 

AE 

1 

EB 

1 

Table  2:  Table  of  normal  behavior  profile  for 
a  program  for  an  iV-gram  size  of  two.  Total 
number  of  unique  iV-grams  is  six,  and  the  total 
number  of  iV-grams  is  nine. 

The  table  shows  the  unique  strings  that  are  cre¬ 
ated  from  a  program’s  BSM  profile  with  their  associ¬ 
ated  frequency.  Each  table  characterizes  the  normal 
behavior  of  the  program  under  non-intrusive  usage. 
Tables  such  as  this  one  are  built  programmatically  for 
all  programs  under  analysis.  In  this  study,  tables  for 
155  different  UNIX  programs  were  constructed.  The 
tables  are  used  by  the  intrusion  detection  algorithm 
to  detect  anomalous  behavior. 

A  single  day  of  data  captured  by  the  BSM  au¬ 
diting  facility  produces  on  the  order  of  hundreds  of 
megabytes  of  data.  This  data  is  then  processed  to 
create  the  tables.  Because  only  unique  strings  are 
stored  in  the  tables,  the  amount  of  data  stored  in  a 
table  is  much  smaller  than  the  size  of  the  data  that 
is  processed  —  typically  three  orders  of  magnitude  in 
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Figure  1:  Average  number  of  iV-grams  in  the  database 
for  a  program.  This  plot  shows  how  the  database 
grows  during  the  first  three  weeks  of  training.  If 
training  stops  when  the  tables  are  very  small,  legit¬ 
imate  system  usage  will  have  high  levels  of  anomalous 
noise.  If  training  proceeds  for  too  long,  many  anoma¬ 
lous  strings  will  be  entered  (and  thereafter  be  consid¬ 
ered  non-anomalous),  resulting  in  a  reduced  ability  to 
detect  anomalous  behavior. 

reduction  in  size.  As  data  continues  to  be  processed 
day  after  day,  the  number  of  new  unique  entries  in 
the  table  drops  off  significantly.  However,  because 
computational  resources  and  storage  are  limited,  it  is 
important  to  determine  at  what  point  the  amount  of 
training  performed  is  good  enough.  In  order  to  de¬ 
termine  a  suitable  stopping  point  in  training,  a  plot 
of  the  amount  of  data  processed  in  training  (in  days 
of  training  data)  versus  the  average  table  size  (z.e., 
the  number  of  unique  iV-grams  in  a  table)  is  shown 
in  Figure  1.  It  is  clear  that  after  the  first  week  of 
training  data,  the  rate  of  increase  in  average  table  size 
slows  significantly.  Training  could  stop  at  this  point. 
However,  AT-grams  do  continue  to  be  added  to  the 
database  after  two  weeks  of  training  data.  In  the  case 
of  the  data  shown  here,  training  on  day  14  shows  an¬ 
other  jump  in  the  number  of  iV-grams  added  to  the 
database. 

4  Exploiting  temporal  locality  of  at¬ 
tacks 

Our  approach  to  intrusion  detection  is  based  on 
the  idea  that  intrusions  can  be  detected  by  observing 
the  behavior  of  individual  programs.  Anomalous  be¬ 
havior  of  a  program  could  indicate  that  the  program 
is  being  subverted  for  intrusive  purposes.  However, 
classifying  the  behavior  of  a  program  as  anomalous 
or  non-anomalous  for  the  purpose  of  detecting  intru¬ 


sions  can  be  rife  with,  errors  because  program  behavior 
is  variable.  Using  a  low  threshold  for  anomalous  be¬ 
havior  can  result  in  a  high  false  alarm  rate  where  a 
non-intrusion  is  classified  as  an  intrusion  (a  false  posi¬ 
tive).  High  false  alarm  rates  will  diminish  the  utility  of 
the  system  very  quickly.  A  high  threshold  for  anoma¬ 
lous  behavior  might  result  in  reduced  false  alarms,  but 
in  a  high  missed  detection  rate  (that  is,  a  high  rate 
of  false  negatives).  Complicating  the  matter  further, 
programs  will  behave  differently  in  different  environ¬ 
ments.  Therefore,  there  are  some  behaviors  a  program 
might  display  that  may  not  appear  to  be  normal,  but 
are  not  subversive,  either.  This  range  of  behavior  re¬ 
sults  in  what  might  be  thought  of  as  anomalous  noise . 
In  this  section,  an  approach  for  distinguishing  intru¬ 
sive  behavior  from  anomalous  noise  is  developed. 

In  order  to  avoid  a  large  number  of  false  positives,  it 
is  necessary  for  an  anomaly-based  intrusion  detection 
system  to  be  able  to  distinguish  anomalous  noise  from 
intrusive  behavior.  The  approach  employed  here  uses 
the  temporal  locality  of  anomalous  sequences  charac¬ 
teristic  of  programs  under  attack  to  distinguish  intru¬ 
sive  behavior  from  simple  anomalous  noise.  Figure  2 
illustrates  the  problem  of  averaging  anomalous  behav¬ 
ior  over  the  duration  of  an  execution  trace. 

In  Figure  2A,  the  anomalous  noise  of  the  program 
under  analysis  is  on  average  less  than  the  threshold,  T. 
From  this  behavior,  a  rule  might  be  derived  that  classi¬ 
fies  a  session  as  intrusive  if  more  than  T%  of  its  events 
are  judged  to  be  anomalous.  However,  this  approach 
has  its  drawbacks  as  illustrated  in  Figures  2B  and  2C. 
A  program  being  used  legitimately  may  occasionally 
generate  (T  +  e)%  anomalous  noise,  as  illustrated  in 
Figure  2B,  resulting  in  frequent  false  positives.  Fur¬ 
ther,  an  intruder  might  try  to  minimize  the  anomalous 
noise  during  an  extended  use  of  a  program  in  order  to 
balance  several  highly  anomalous,  subversive  actions. 
Thus,  the  intruder  could  intentionally  slip  under  the 
T%  threshold  for  the  program’s  average  anomalous  be¬ 
havior  to  avoid  detection,  as  illustrated  in  Figure  2C. 

In  order  to  address  this  problem,  the  temporal  lo¬ 
cality  of  anomalous  sequences  characteristic  of  attacks 
against  programs  can  be  exploited.  When  a  program 
is  being  misused  at  the  user  level  of  abstraction,  the 
program  will  make  a  sequence  of  anomalous  system 
calls.  That  is,  program  misusage  tends  to  result  in 
sequences  of  anomalous  system  calls  as  in  Figure  2C. 
Averaging  the  number  of  anomalous  sequences  of  the 
entire  execution  trace  can  result  in  the  intrusion  be¬ 
ing  washed  out  in  the  anomalous  noise.  Thus,  it  is 
essential  to  look  for  temporally  co-located  anomalous 
sequences  by  dividing  the  execution  trace  into  fixed- 
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Figure  2:  Possible  usages  of  a  program  in  terms  of  anomalous  behavior.  If  some  threshold  T  (displayed  as 
the  dotted  line)  is  applied  to  the  entire  execution  of  a  program,  false  positives  and  false  negatives  may  occur 
frequently.  A)  During  a  normal  execution,  the  anomalous  noise  is,  on  average,  less  than  T.  B)  Due  to  normal 
statistical  variance,  the  anomalous  noise  will,  on  average,  slightly  exceed  T,  resulting  in  a  false  positive.  C)  A 
knowledgeable  intruder  could  minimize  the  anomalous  noise  of  a  program  (by  performing  very  mundane  actions) 
so  that,  on  average,  the  subversive  behavior  does  not  exceed  T,  resulting  in  a  false  negative. 


size  intervals  of  temporal  locality  that  are  reflective 
of  macro-level  user  events.  Because  each  interval  has 
a  fixed  size  much  smaller  than  the  overall  execution 
trace,  it  is  possible  to  avoid  washing  out  a  few  highly 
anomalous  actions  over  long  program  executions.  Us¬ 
ing  this  approach,  it  would  be  desirable  for  the  pro¬ 
gram  analyzed  in  Figure  2C  to  choose  a  fixed  interval 
size  on  the  order  of  the  size  of  the  disturbance  shown 
in  the  figure. 

5  Using  equality  matching  for  intru¬ 
sion  detection 

The  algorithm  we  use  for  detecting  intrusions  is 
simple  but  effective.  With  an  approach  similar  to 
the  that  of  [Forrest  et  ah,  1997],  we  employ  equality 
matching  of  sequences  of  system  calls  captured  during 
online  usage  against  those  stored  in  the  database  built 
from  the  normal  program  behavior  profile.  If  the  se¬ 
quence  of  BSM  events  captured  during  online  usage  is 
not  found  in  the  database,  then  an  anomaly  counter 
is  incremented.  This  technique  is  predicated  on  the 
ability  to  capture  the  normal  behavior  of  a  program 
in  a  database.  If  the  normal  behavior  of  a  program 
is  not  adequately  captured,  then  the  false  alarm  rate 
is  likely  to  be  high.  On  the  other  hand,  if  the  normal 
behavior  profile  built  for  a  program  includes  intrusive 
behavior,  then  future  instances  of  the  intrusive  behav¬ 
ior  are  likely  to  go  undetected.  Finally,  it  is  important 
that  the  range  of  possible  behavior  patterns  is  much 
larger  than  the  range  of  normal  behavior  patterns,  be¬ 
cause  detection  of  intrusive  events  is  only  made  possi¬ 
ble  when  the  intrusive  behavior  patterns  are  different 
from  the  normal  behavior  patterns.  The  more  com¬ 
pact  the  representation  of  normal  behavior  and  the 
larger  the  range  of  possible  behavior,  the  better  de¬ 


tection  capacity  this  equality  matching  technique  will 
have.  The  ratio  of  normal  behavior  patterns  to  pos¬ 
sible  behavior  patterns  provides  an  indication  of  the 
detection  capacity  of  the  technique.  The  smaller  this 
ratio,  the  better  the  detection  capacity. 


Program 

■#  of  Unique  BSM  Events 

cat 

7 

in. telnetd 

14 

login 

17 

mail 

13 

pt_chinod 

10 

quota 

7 

sendmail 

18 

sh 

10 

tcsh 

13 

Table  3:  Number  of  unique  BSM  events  for  pro¬ 
grams  run  in  a  sample  telnet  session. 

Capturing  system  calls  via  the  BSM  provides  a 
broad  range  of  possible  behavior.  There  are  approxi¬ 
mately  200  different  BSM  events  that  can  be  recorded. 
The  iV-grams  described  in  Section  3  represent  a  se¬ 
quence  of  N  consecutive  BSM  events.  Therefore  a 
single  iV-gram  can  have  200^  possible  combinations. 
In  practice,  however,  a  program  will  normally  make 
only  about  10  to  20  different  system  calls.  Table  3 
shows  the  number  of  different  BSM  events  for  pro¬ 
grams  in  a  sample  telnet  session  under  non-intrusive 
conditions. 

Using  20  BSM  events  as  an  example,  this  gives  rise 
to  20^  possible  iV-grams  during  normal  operation. 
The  ratio  between  possible  BSM  events  during  normal 
behavior  to  all  possible  system  calls  is  1/10N.  Thus, 
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as  N  increases,  the  ratio  of  normal  BSM  events  to  pos¬ 
sible  BSM  events  decreases  as  a  power  of  10.  In  prac¬ 
tice,  the  number  of  iV-grams  produced  by  a  program  is 
much  smaller  than  20iV,  mainly  because  either  certain 
orderings  never  occur  e.g.,  {exit  execve},  or  because 
certain  orderings  do  not  correspond  to  what  a  par¬ 
ticular  program  would  ever  do.  Our  results  find  that 
for  N  =  6,  each  program  makes  approximately  100 
to  200  different  A’- grams,  rather  than  206.  Thus,  the 
ratio  of  normal  sequences  of  BSM  events  to  possible 
sequences  of  BSM  events  is  much  smaller  in  practice 
than  our  pessimistic  scenario. 


Interval 

Unit  Contained 

Threshold 

session 

file 

ST 

file 

window 

FT 

window 

iV-gram 

WT 

iV-gram 

BSM  event 

— 

Table  4:  Using  intervals  of  fixed  sizes  and 
thresholds  to  exploit  temporal  locality  of  at¬ 
tacks. 

The  approach  employed  here  exploits  temporal  lo¬ 
cality  of  anomalous  sequences  for  detecting  intrusions. 
That  is,  rather  than  averaging  the  number  of  anoma¬ 
lous  sequences  out  of  the  total  number  of  sequences, 
we  employ  thresholding  functions  in  fixed-size  inter¬ 
vals,  where  the  fixed- size  interval  is  much  smaller  than 
the  total  execution  trace.  A  session  is  considered  to 
be  intrusive  if  it  contains  an  anomalous  execution  of 
a  program.  A  program  is  considered  anomalous  if  a 
portion  of  its  windows  is  anomalous.  A  window  is 
considered  anomalous  if  a  portion  of  its  iV-grams  is 
anomalous.  An  iV-gram  is  considered  anomalous  if  it 
cannot  be  found  in  the  database  corresponding  to  the 
program  currently  being  checked. 

Table  4  shows  the  fixed-size  intervals,  the  units 
they  contain,  and  their  thresholds  that  are  used  to 
detect  anomalous  behavior.  When  the  threshold  for 
a  fixed  interval  —  such  as  a  window  of  iV-grams  — 
is  exceeded,  the  whole  interval  is  marked  as  anoma¬ 
lous.  Then  a  thresholding  function  is  applied  at  the 
next  level  up  in  abstraction  using  the  marked  anoma¬ 
lous  interval  to  determine  if  an  intrusion  has  occurred. 
For  instance,  if  a  window  is  marked  as  anomalous  be¬ 
cause  its  threshold,  WT,  for  anomalous  iV-grams  is 
exceeded,  then  this  window  is  used  as  part  of  the  count 
for  file  intervals  to  determine  if  the  file  threshold  FT 
is  exceeded.  Ultimately,  the  session  threshold,  ST, 
must  be  exceeded  for  the  session  to  be  labeled  as  an 
intrusion.  The  thresholds  are  all  configurable  and  the 
tuning  of  the  thresholds  will  impact  the  performance 


of  the  system  as  showm  in  the  following  sections. 

5.1  Tuning  parameters  of  the  system 
The  performance  of  the  system  is  highly  dependent 
on  several  independent  parameters.  Adjusting  any  one 
of  several  parameters  can  result  a  large  change  in  the 
performance  of  the  system,  and  there  is  some  trade-off 
involved  with  each  parameter.  The  parameters  are: 


•  A-gram  Size  When  N  is  very  small,  less  tem¬ 
poral  information  is  available.  In  the  case  where 
N  is  one,  all  temporal  information  is  lost.  A  very 
large  value  for  N  results  in  iV-grams  that  carry 
too  much  information.  Each  iV-gram  should  be  a 
general  sequence  of  events  that  does  not  necessar¬ 
ily  reflect  the  context  in  which  it  occurs.  As  iV- 
grams  carry  more  contextual  information,  anoma¬ 
lous  noise  rises. 

•  Window  Size  The  window  size  is  the  number  of 
iV-grams  in  a  window.  A  window  is  meant  to  con¬ 
tain  a  relatively  high-level  user  event.  If  the  win¬ 
dow  is  too  small,  it  might  not  be  able  to  contain 
an  entire  event,  and  short  bursts  of  anomalous  N- 
grams,  which  should  be  averaged  into  the  anoma¬ 
lous  noise,  extend  through  the  entire  window,  re¬ 
sulting  in  the  window  being  falsely  classified  as 
anomalous.  If  the  window  size  is  very  large,  it 
might  encompass  many  iV-grams  not  related  to 
a  subversive  action  occurring  during  the  window, 
and  thus  the  subversive  action  might  blend  into 
the  anomalous  noise. 

•  Window  Threshold  This  threshold  is  the  value 
that  the  ratio  of  anomalous  iV-grams  in  a  window 
to  total  iV-grams  in  a  window  must  exceed  before 
the  window  is  flagged  as  anomalous. 

•  File  Threshold  This  threshold  is  the  value  that 
the  ratio  of  anomalous  windows  in  the  execution 
of  a  program  to  total  windows  in  a  program  must 
exceed  before  the  execution  of  the  program  is  con¬ 
sidered  to  be  anomalous. 


•  Extent  of  Training  The  amount  of  data  used  for 
training  is  constrained  both  by  processing  ability 
(as  training  the  system  is  computationally  very 
expensive),  and  the  amount  of  training  data  avail¬ 
able.  The  ideal  amount  of  training  results  in  a  set 
of  iV-grams  being  collected  which  characterizes 
the  behavior  of  a  program  under  normal  opera¬ 
tion.  Too  little  training  results  in  very  high  levels 
of  anomalous  noise;  too  much  training  results  in 
a  decreased  ability  to  recognize  truly  anomalous 
events  as  anomalous. 
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Figure  3:  Performance  of  the  equality  matching  intrusion  detection  system  with  a  window  size  of  10  and  an 
iV-gram  size  of  two.  These  graphs  display  the  percentage  of  data  that  is  correctly  classified  when  the  data  is  A) 
non-intrusive,  and  B)  intrusive.  As  the  file  and  window  threshold  ratios  rise,  the  system  becomes  more  tolerant  of 
anomalous  behavior.  Thus,  lower  thresholds  result  in  an  increased  ability  to  detect  intrusions,  but  also  a  greater 
likelihood  of  mis  classification  of  non-intrusions. 


•  Session  Threshold  This  threshold  is  the  value 
above  which  the  score  for  a  session  must  exceed 
to  be  flagged  as  intrusive.  This  score  corresponds 
to  the  anomalous  measure  of  the  most  anomalous 
file. 

The  extent  of  training  is  typically  limited  by  the 
amount  of  data  and  computational  resources  on  hand. 
As  shown  in  Figure  1,  the  amount  of  new  jV-grams 
added  to  program  databases  leveled  off  on  average  af¬ 
ter  adding  one  week  of  training  data.  Surprisingly, 
even  with  only  two  weeks  of  training  data,  the  equal¬ 
ity  matching  system  was  able  to  detect  intrusions  with 
fairly  high  accuracy. 

Varying  the  iV-gram  size  and  the  window  size  will 
impact  the  performance  of  the  system.  Various  N - 
gram  sizes  tested  ranged  from  two  to  50.  The  anomaly 
detection  capabilities  drop  sharply  for  values  of  N 
larger  than  12.  Therefore,  we  focused  on  smaller  val¬ 
ues  for  N.  The  smallest  window  size  tested  consisted 
of  10  iV-grams. 

To  optimize  the  file  and  window  thresholds,  the  per¬ 
formance  of  the  system  was  measured  against  these 
two  variables  while  fixing  the  JV-gram  size  and  the 
window  size.  Figure  3A  shows  the  performance  of  the 
system  with  respect  to  non-intrusive,  normal  data.  As 
expected,  as  we  increase  the  window  and  file  thresh¬ 
olds,  the  performance  of  the  system  in  classifying  non- 
intrusive  data  improves.  In  other  words,  increasing 
these  thresholds  increases  the  tolerance  for  anomalous 
noise  in  a  session.  Figure  3B  shows  that  increasing 
these  thresholds  for  intrusion  data  decreases  the  per¬ 


formance  of  the  system.  That  is,  as  the  tolerance  for 
anomalous  noise  is  increased,  the  rate  of  correct  clas¬ 
sifications  will  decrease  due  to  missed  intrusions  (false 
negatives).  Notice  in  both  these  plots  that  the  (0.1, 
0.1)  threshold  appears  to  be  a  turning  point  where 
performance  sharply  changes.  This  is  the  optimum 
threshold  point  given  the  fixed  parameters.  Plots  such 
as  these  are  used  to  determine  optimal  thresholds  for 
tuning  the  equality  matching  intrusion  system. 

To  determine  optimal  iV-gram  size  and  optimal 
window  size,  plots  similar  to  Figure  3  were  constructed 
except  one  parameter  was  fixed,  while  the  other  was 
varied.  For  instance,  to  determine  optimal  iV-gram 
size,  the  window  size  was  fixed  at  20,  and  numerous 
plots  similar  to  Figure  3  were  constructed  for  values  of 
N  ranging  from  two  to  12  in  increments  of  two.  Using 
this  process  for  both  iV-gram  sizes  and  window  sizes, 
the  optimal  performance  was  found  for  N  =  6  and 
window  size  of  20.  Figure  4  shows  the  performance 
of  the  equality  matching  system  with  these  optimal 
parameters  under  varying  file  and  window  thresholds. 
Figure  4A  shows  the  large  plateau  in  the  center  of 
the  plane,  which  indicates  that  there  is  a  large  range 
of  window  and  file  thresholds  which  produce  optimal 
performance.  Figure  4B  also  shows  a  well-defined  and 
broad  region  of  good  performance  for  intrusion  data. 
Having  a  large  and  well-defined  range  of  performance 
for  these  thresholds  is  important  because  these  thresh¬ 
olds  may  be  varied  for  different  programs  and  in  dif¬ 
ferent  environments. 
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Figure  4:  Performance  of  the  equality  matching  intrusion  detection  system  for  optimal  window  size  of  20  and 
optimal  iV-gram  size  of  six.  These  graphs  display  the  percentage  of  data  that  is  correctly  classified  when  the  data 
is  A)  non-intrusive,  and  B)  intrusive.  The  large  plateau  in  the  center  of  these  plots  indicates  good  performance 
over  a  large  range  of  file  and  window  thresholds. 


In  order  to  insure  that  the  optimal  parameters 
found  were  generally  applicable,  and  not  simply  spe¬ 
cific  to  the  data  being  used,  this  process  was  re¬ 
peated  for  different  training  sets  and  intrusive  and 
non-intrusive  sessions.  The  results  from  perform¬ 
ing  this  analysis  on  other  data  sets  showed  consis¬ 
tently  good  performance  in  correctly  classifying  non- 
intrusive  data,  but  varying  performance  in  classifying 
intrusion  data.  This  result  is  expected  because  the 
ratio  of  intrusive  data  to  non-intrusive  data  in  the 
test  sets  is  very  small.  Thus,  one  would  expect  the 
performance  of  the  system  to  vary  more  widely  when 
presented  the  rare  intrusion  data.  Nonetheless,  the  re¬ 
sults  showed  that  the  IV-gram  size  of  six  and  window 
size  of  20  were  in  fact  optimal  for  the  different  data 
sets.  Results  from  testing  the  system  on  new  data  sets 
are  shown  in  Figure  5. 

6  Computing  the  probability  of  detec¬ 
tion  versus  the  probability  of  false 
alarm 

In  order  to  judge  the  effectiveness  of  this  intrusion 
detection  system,  it  is  useful  to  compute  the  prob¬ 
ability  of  detection  against  the  probability  of  false 
alarm  for  different  operating  characteristics,  such  as 
the  tunable  thresholds.  Previous  evaluations  of  intru¬ 
sion  detection  systems  tended  to  focus  exclusively  on 
probability  of  detection  while  ignoring  the  probabil¬ 
ity  of  false  alarm.  False  alarms  are  the  Achilles  heal 
of  most  intrusion  detection  systems.  The  higher  the 
false  alarm  rate,  the  less  effective  the  system  is.  If  the 
intrusion  detection  system  cries  wolf  too  frequently, 


then  the  user  will  abandon  the  system  completely.  The 
data  provided  by  MIT’s  Lincoln  Laboratory  embedded 
attack  sessions  within  normal  sessions,  which  permits 
measurement  of  detection  and  the  false  alarm  rates 
simultaneously. 

A  measure  of  the  overall  effectiveness  of  a  given 
intrusion  detection  system  can  be  provided  by  the  re¬ 
ceiver  operating  characteristic  (ROC)  curve.  An  ROC 
curve  is  a  parametric  curve  that  is  generated  by  vary¬ 
ing  the  threshold  of  the  intrusive  measure ,  which  is  a 
tunable  parameter,  and  computing  the  probability  of 
detection  and  the  probability  of  false  alarm  at  each 
operating  point.  The  curve  is  a  plot  of  the  likelihood 
that  an  intrusion  is  detected,  against  the  likelihood 
that  a  non-intrusion  is  misclassified  for  a  particular 
parameter,  such  as  a  threshold.  The  ROC  curve  can 
be  used  to  determine  the  performance  of  the  system 
for  any  possible  operating  point.  Thus,  it  can  be  ap¬ 
plied  to  different  file  and  window  thresholds  to  judge 
performance.  ROC  curves  were  generated  for  our  sys¬ 
tem  for  the  labeled  training  data  and  are  illustrated  in 
Figure  6  and  Figure  7.  The  results  are  for  data  that 
the  system  had  not  seen  before,  i.e .,  data  on  which  it 
had  not  trained. 

Regardless  of  the  intrusion  detection  system  used, 
two  points  remain  fixed  on  the  ROC  curve:  (0,0)  and 
(1,1).  The  (0,0)  point  is  achieved  when  the  threshold 
is  set  to  1,  in  which  case  no  intrusions  will  be  de¬ 
tected  because  more  than  100%  of  the  intervals  used 
for  anomaly  detection  would  have  to  be  anomalous  to 
be  considered  intrusive.  This  threshold  gives  a  0%  rate 
of  correct  detection  of  intrusions,  and  no  false  alarms. 
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Figure  5:  Performance  of  the  intrusion  detection  system  with  a  window  size  of  20  and  an  iV-gram  size  of  six  on 
new  data.  The  variation  in  performance  in  intrusive  data  results  from  the  fact  that  testing  is  performed  on  much 
more  normal  data  than  intrusive  data.  Thus,  normal  statistical  variation  have  a  larger  effect  on  the  intrusive 
data. 


The  (1,1)  point  is  achieved  when  the  threshold  is  set 
to  0  (inclusive),  which  means  that  all  sessions  will  be 
classified  as  intrusions  giving  perfect  detection  of  in¬ 
trusions  and  a  100%  false  alarm  rate.  The  power  of 
the  intrusion  detection  system  can  be  measured  by  the 
area  under  the  curve  for  a  given  intrusion  detection 
system  between  these  points. 

To  better  understand  this  performance  measure, 
consider  an  intrusion  detection  oracle  that  scores  a 
session  with  a  value  of  one  if  and  only  if  it  is  an  intru¬ 
sion,  and  a  value  of  zero  otherwise.  The  resulting  ROC 
curve  would  actually  not  be  a  curve,  but  rather,  a  sin¬ 
gle  point  at  the  location  (0,1)  since  it  is  would  detect 
intrusions  with  a  likelihood  of  1/1,  and  it  would  mis- 
classify  non-intrusions  with  a  likelihood  of  0/1.  Fur¬ 
ther,  as  the  threshold  varied  between  zero  and  one  (ex¬ 
clusive),  there  would  be  no  change  in  the  way  sessions 
are  classified,  so  the  parametric  value  would  remain 
at  that  one  point.  This  can  be  called  the  oracle  point. 
However,  at  the  thresholds  of  1  and  0  (inclusive),  the 
(0,0)  and  (1,1)  points  remain  fixed.  Connecting  these 
points  and  computing  the  area  under  the  curve  gives 
an  area  of  1,  or  a  power  of  100%. 

At  the  other  end  of  the  spectrum,  consider  the  curve 
that  defines  the  worst  possible  intrusion  detection  sys¬ 
tem.  The  ROC  curve  for  the  worst  case  scenario  is  the 
y  =  x  line  shown  in  Figure  6.  Assume  a  system  that 
randomly  assigns  a  value  between  zero  and  one  for 
every  session.  Starting  from  a  threshold  of  zero,  we 
derive  the  (1,1)  point  because  all  sessions  would  be 
classified  as  intrusions.  As  the  session  threshold  in¬ 
creases,  the  likelihood  of  both  correctly  classifying  an 


intrusion  and  incorrectly  classifying  a  non-intrusion 
decrease  at  the  same  rate  until  the  session  threshold 
is  1  (corresponding  to  the  point  (0,0)).  The  power  of 
this  system  is  50%,  corresponding  to  the  area  under 
this  curve  of  0.5.  If  an  intrusion  detection  system  were 
to  perform  even  worse  than  this  curve,  one  would  sim¬ 
ply  invert  each  classification  to  do  better.  Therefore, 
the  y  =  x  plot  represents  the  benchmark  by  which  all 
intrusion  detection  system  should  do  better. 

The  ROC  curve  allows  the  end  user  of  an  intrusion 
detection  system  to  assess  the  trade-off  between  detec¬ 
tion  ability  and  false  alarm  rate  in  order  to  properly 
tune  the  system  for  acceptable  tolerances.  For  ex¬ 
ample,  Figure  6  shows  ROC  curves  produced  with  a 
window  size  of  20  and  an  iV-gram  size  of  six.  These 
parameters  were  found  to  be  optimal  from  our  previ¬ 
ous  analyses.  In  the  ROC  curves  plotted  in  Figure  6 
and  Figure  7,  the  window  threshold  was  held  constant 
for  each  curve,  while  the  session  threshold  was  var¬ 
ied.  The  session  threshold  is  the  value  above  which 
the  score  for  a  session  must  exceed  to  be  flagged  as 
possibly  intrusive.  Recall  that  the  score  reported  for 
a  session  is  the  measure  of  the  most  anomalous  file  in 
that  session. 

Three  ROC  curves  axe  shown  in  Figure  6.  The 
y  —  x  curve  is  shown  as  the  benchmark  for  the  worst 
case  scenario.  The  top  curve  corresponds  to  a  window 
threshold  fixed  at  zero,  and  the  other  corresponds  to 
a  window  threshold  fixed  at  0.2.  The  ROC  curve  for 
the  window  threshold  of  0.2  encloses  an  area  of  0.85. 
The  ROC  curve  for  the  window  threshold  of  0  encloses 
an  area  of  0.91.  No  value  for  the  window  threshold  re- 
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Figure  6:  Receiver  operating  characteristic  (ROC)  curve  for  optimal  parameters  after  two  weeks  of  training  data. 
The  ROC  curve  allows  an  intrusion  detection  system  user  to  adjust  the  sensitivity  of  the  intrusion  detection 
system.  This  graph  shows  both  the  worst  possible  ROC  curve  ( i.e .,  y  =  x),  as  well  as  a  ROC  curve  generated 
from  actual  data. 


suited  in  an  enclosed  area  greater  than  0.91.  Thus,  a 
window  threshold  of  0  is  optimal.  However,  there  is 
a  range  of  possible  values  for  the  session  threshold  on 
this  optimal  curve.  Since  the  oracle  point  defines  the 
ideal  intrusion  detection  ability,  the  point  on  the  curve 
closest  to  the  oracle  point  results  in  the  optimal  sensi¬ 
tivity.  Figure  7  A  shows  the  ROC  curve  for  the  window 
threshold  of  0,  with  several  points  labeled  with  the  ses¬ 
sion  threshold  value  to  which  they  correspond.  It  is 
clear  that  the  point  at  (0.04,  0.89),  which  corresponds 
to  a  session  threshold  of  0.06,  is  closest  to  the  oracle 
point.  In  many  cases,  the  ability  to  detect  89%  of  all 
intrusions  and  produce  a  false  alarm  rate  only  4%  is 
adequate.  In  some  systems,  this  performance  may  not 
be  adequate.  For  instance,  a  false  alarm  rate  of  4% 
might  be  too  high.  A  difficult  problem  then  arises: 
how  should  the  sensitivity  of  the  system  be  adjusted, 
taking  into  account  that  by  lowering  the  sensitivity, 
one  not  only  decreases  the  number  of  false  alarms,  but 
also  decreases  the  number  of  intrusions  detected.  The 
scaling  of  the  axes  plays  an  important  role  in  solving 
this  problem. 

By  appropriately  scaling  the  axes,  it  is  possible  to 
once  again  reduce  the  problem  of  selection  of  a  session 
threshold  to  finding  the  distance  to  the  oracle  point. 
A  site  that  cares  more  about  reducing  false  alarms 
than  detecting  all  intrusions  should  stretch  the  false- 
alarm  axis  (x-axis).  If  detection  of  all  intrusions  is 
very  important,  then  the  intrusion-detection  axis  (y- 
axis)  should  be  scaled  appropriately.  The  ROC  curve 
in  Figure  7B  is  the  same  as  that  in  Figure  7A,  however, 
the  axes  have  been  scaled  for  a  site  that  places  greater 
emphasis  on  false  alarm  reduction.  In  this  case,  the 


point  on  the  curve  closest  to  the  oracle  point  is  (0.03, 
0.78),  and  occurs  when  the  session  threshold  is  0.1. 
Thus,  it  is  possible  to  achieve  a  lower  false  alarm  rate 
(3%)  at  a  cost  of  reducing  the  intrusion  detection  rate 
(78%)  by  using  a  window  threshold  of  0  and  a  session 
threshold  of  0.1. 

7  Discussion  and  future  work 

The  analyses  presented  here  are  for  perhaps  the 
simplest  intrusion  detection  algorithm  —  equality 
matching  —  for  detecting  intrusions  by  profiling  pro¬ 
gram  behavior.  The  real  constraints  of  this  approach 
are  the  computing  and  storage  capacity  necessary  to 
process  data,  and  the  necessity  for  good  training  data 
in  the  first  place.  All  experiments  described  here  used 
two  weeks  of  BSM  audit  data  for  training.  The  bene¬ 
fit  of  this  approach  is  that  BSM  is  an  auditing  facility 
widely  available  on  Solaris  operating  systems.  There¬ 
fore,  no  special  programs  need  to  be  written  to  cap¬ 
ture  the  data  from  which  program  behavior  profiles 
are  built.  However,  because  training  and  testing  data 
come  from  the  same  finite  pool  of  data,  and  since  once 
data  is  used  for  training,  it  cannot  be  used  for  testing, 
it  is  difficult  to  produce  significant  test  results  when 
most  of  the  available  data  has  been  used  for  training. 
Therefore,  our  ability  to  determine  the  optimal  extent 
of  training  was  limited  by  these  constraints.  However, 
even  with  two  weeks  (which  is  almost  certainly  sub- 
optimal),  we  were  able  to  produce  results  that  indi¬ 
cated  that  the  simple  equality  matching  technique  for 
program  behavior  profiling  provides  sufficiently  good 
performance  for  intrusion  detection. 

Future  directions  of  this  work  will  extend  the  intru- 
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Figure  7:  ROC  curve  with  scaled  axes.  By  scaling  the  axes,  the  task  of  determining  a  session  threshold  reduces 
to  minimizing  the  distance  to  an  “oracle  point”  (in  this  case,  that  is  (0,1)).  Again,  both  the  worst  possible  curve, 
and  an  actual  ROC  curve  are  shown. 


sion  detection  algorithm  in  two  similar,  but  different 
directions.  A  logical  extension  of  the  equality  match¬ 
ing  approach  is  to  say  that  an  iV-gram  is  less  anoma¬ 
lous  if  it  resembles  other  strings  that  have  been  seen 
before,  and  more  anomalous  if  it  does  not  resemble 
any  of  those  strings.  We  intend  to  implement  two  dif¬ 
ferent  algorithms  that  use  this  notion.  First,  we  will 
use  data  interpolation  with  distance  functions  to  sta¬ 
tistically  determine  how  close  a  given  iV-gram  matches 
the  normal  behavior  profile.  Similar  approaches  have 
been  successful  in  areas  like  density  estimation  and 
nonparametric  regression.  We  expect  this  approach 
to  reduce  the  number  of  false  positives  due  to  anoma¬ 
lous  noise.  Second,  we  are  training  neural  networks 
to  make  connections  between  normal  data,  and  con¬ 
versely,  intrusive  data.  Using  neural  networks,  we  aim 
to  improve  the  online  performance  of  our  system. 
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Abstract 

Intrusion  detection  systems  like  NIDES  depend  on 
the  ability  to  characterize  a  user’s  past  behavior  based 
on  his/her  usage  patterns .  The  characterization  is 
typically  made  in  terms  of  statistics  drawn  on  sys¬ 
tem  parameters  such  as  CPU,  I/O  and  network  loads , 
and  file  access  patterns.  For  example,  NIDES  main¬ 
tains  statistics  on  approximately  25  such  parameters 
for  each  user.  The  cost  of  data  collection,  statistics 
computation,  and  intrusion  detection  are  directly  pro¬ 
portional  to  the  number  of  parameters  maintained  per 
user.  If  we  would  like  to  achieve  real-time  responses 
to  intrusion  detection,  then  we  need  to  minimize  the 
number  of  parameters  without  adversely  affecting  the 
detection  capabilities. 

In  this  paper,  we  propose  to  use  some  of  the  feature 
reduction  and  selection  techniques  commonly  used  in 
data  mining  applications  to  reduce  the  computational 
and  storage  requirements  of  the  intrusion  detection 
methods.  Since  typically  several  of  the  user  behavioral 
parameters  are  correlated,  applying  these  techniques 
may  reduce  the  number  of  parameters  needed  to  repre¬ 
sent  the  user  behavior. 

1  Introduction 

With  the  ever  increasing  trend  to  make  computer 
systems  and  databases  easily  accessible  through  the 
internet,  there  is  also  an  increasing  fear  of  intruders 
into  the  systems.  One  method  of  detecting  intruders, 
who  might  enter  the  system  in  the  guise  of  legitimate 
users  is  to  maintain  an  audit  of  user  activity  [2,  3,  9]. 
Each  audit  record  would  summarize  the  user  activity 


or  a  process  activity  in  terms  of  a  set  of  feature  values. 
One  of  the  main  challenges  in  intrusion  detection  is 
to  summarize  the  historical  audit  data  so  that  when 
current  activity  is  compared  with  it,  one  can  classify 
it  as  legitimate  or  intrusive.  Since  the  comparisons 
need  to  be  made  on-line,  when  the  activity  is  taking 
place,  it  is  necessary  to  minimize  the  processing  time 
for  such  detections.  This  also  puts  a  constraint  on  the 
size  of  the  data  we  wish  to  keep  in  the  summary. 

Data  mining  techniques  deal  with  very  large  vol¬ 
umes  of  data  [14,  8].  In  order  for  these  techniques  to 
be  effective  in  on-line  processing  of  queries,  they  at¬ 
tempt  to  reduce  the  data  that  they  need  to  process  in 
answering  a  query.  These  are  referred  to  as  data  re¬ 
duction  techniques.  Feature  reduction  is  one  of  many 
such  techniques  [13,  14]. 

In  this  paper,  we  investigate  the  effectiveness  of  in¬ 
tegrating  some  data  reduction  techniques  of  data  min¬ 
ing  with  the  intrusion  detection  techniques.  The  work 
presented  in  this  paper  is  preliminary  in  nature.  Thus 
the  insights  gained  are  explained  more  through  exam¬ 
ples  rather  than  any  formal  proofs.  As  we  continue  to 
make  progress  in  these  efforts,  we  hope  to  obtain  more 
concrete  evidence. 

In  particular,  we  look  at  the  significance  tests  on 
features  that  determine  whether  or  not  a  feature  con¬ 
tributes  in  correctly  classifying  an  observed  user  activ¬ 
ity  as  intrusive  or  non-intrusive.  The  activity  itself  is 
characterized  in  terms  of  a  set  of  features  in  an  audit 
record.  We  also  look  at  measures  of  mutual  signifi¬ 
cance.  These  measures  are  useful  when  all  features  in 
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an  audit  record  are  not  completely  independent.  In 
fact,  dependencies  do  exist  among  features  in  real  sys¬ 
tems.  When  the  degree  of  mutual  dependency  is  high, 
then  we  could  possibly  eliminate  one  or  more  of  the 
features  from  the  audit  record  without  affecting  the 
intrusion  capabilities.  We  also  look  at  logic  methods 
that  can  infer  classification  rules  from  a  given  set  of 
audit  records.  This  scheme  also  reduces  the  amount  of 
data  that  need  to  be  maintained  about  historical  be¬ 
havior  of  users.  We  find  that  all  these  techniques  are 
quite  useful  in  data  reduction  in  intrusion  detection 
schemes. 

The  paper  is  organized  as  follows.  In  Section  2, 
we  summarize  the  use  of  statistical  methods  in  intru¬ 
sion  detection.  In  Section  3,  we  discuss  the  data  re¬ 
duction  techniques  available  in  data  mining.  We  also 
discuss  the  classification  methods.  Section  4  discusses 
in  detail  three  feature-reduction  methods  used  in  data 
mining — significance  testing,  mutual  significance,  and 
logic  methods.  Section  5  illustrates  these  techniques 
through  examples.  In  Section  6,  we  analyze  the  effect 
of  data  reduction  on  intrusion  detection  capability  of 
systems.  We  look  at  systems  with  independent  fea¬ 
tures,  linearly  dependent  features,  and  features  with 
non-linear  dependencies.  Finally,  Section  7  has  a  sum¬ 
mary  of  current  work  and  plans  for  future  work. 

2  Intrusion  Detection 

Detecting  intruders  in  a  computer  system  is  vital 
to  many  organizations.  This  is  especially  relevant 
to  commercial  and  military  organizations  since  they 
maintain  several  key  data  on  their  computer  systems. 
While  preventing  intruders  by  means  of  firewalls  and 
authentication  mechanisms  is  a  necessary  step,  the  or¬ 
ganizations  would  also  like  to  be  alerted  when  suspi¬ 
cious  activity  is  observed  on  the  system. 

NIDES,  the  Next-generation  Intrusion  Detection 
Expert  System,  is  developed  at  SRI  International  for 
the  purpose  of  detecting  anomalous  behavior  in  com¬ 
puter  system  [2, 3].  The  system  is  based  on  statistics — 
the  normal  behavior  of  a  user  is  represented  by  a  set 
of  parameters.  Statistic  are  dynamically  calculated 
based  on  the  user’s  behavior.  Whenever  a  user’s  be¬ 
havior  (expressed  in  terms  of  audit  records)  is  found 
to  be  (statistically)  significantly  deviate  from  the  nor¬ 
mal  statistic,  an  alarm  is  raised.  In  order  to  keep  up 
with  the  changing  behavior  of  a  legitimate  user,  the 
system  gives  higher  weight  to  the  recent  behavior  and 
lower  weight  to  the  past.  This  is  achieved  by  defining 
half-life  for  the  statistic. 

Since  no  single  measure  may  characterize  the  be¬ 
havior  of  a  user,  NIDES  measures  and  maintains 
statistic  on  several  measures.  Some  of  the  measures 


that  were  used  in  one  of  their  applications,  Safeguard, 
include  user  time,  system  time,  number  of  open  files, 
elapsed  process  time,  integral  of  memory  usage,  num¬ 
ber  of  page  faults,  etc.  [2].  For  each  measure,  a  proba¬ 
bility  distribution  of  short-term  (immediate  past)  and 
long-term  behaviors  was  constructed. 

The  degree  of  difference  between  long-term  profile 
and  short-term  profile  is  measured  in  terms  of  a  Q- 
statistic.  This  statistic  is  maintained  for  each  measure. 
Whenever  a  new  audit  record  is  received  by  the  sys¬ 
tem,  indicating  the  current  activity,  the  NIDES  sys¬ 
tem  generates  a  vector  of  Q  values.  Here,  large  Q  val¬ 
ues  indicate  deviation  from  the  expected  behavior  and 
hence  are  suspicious.  The  distribution  of  Q  for  each 
measure  is  maintained  as  a  histogram  of  bins.  In  fact, 
when  an  audit  record  is  received,  first  an  S-statistic 
is  computed  for  each  feature  and  the  sum  of  squares 
of  the  S-statistic.  This  is  referred  to  as  T2-statistic. 
This  statistic  along  with  the  probability  distributions 
of  the  past  is  used  to  generate  a  probability  of  such 
occurrence.  This  in  turn  is  used  to  raise  alarms. 

The  computational  and  storage  requirements  in 
NIDES  is  directly  proportional  to  the  number  of  mea¬ 
sures  (or  features)  being  monitored.  For  each  mea¬ 
sure,  a  histogram  and  several  statistic  are  maintained. 
This  information  is  updated  either  after  every  audit 
record  or  after  a  certain  period  of  time  (or  after  cer¬ 
tain  number  of  audit  records).  This  processing  is  to  be 
done  sufficiently  frequently  so  as  to  avoid  false  alarms 
as  well  as  the  risk  of  missing  detection  of  legitimate 
intrusions.  Several  computations  are  also  needed  to 
determine  whether  or  not  an  intrusion  has  occurred. 

While  it  is  perfectly  valid  that  we  need  to  charac¬ 
terize  the  behavior  of  a  user  in  terms  of  several  mea¬ 
sures,  there  is  also  a  danger  of  keeping  track  of  to 
many  measures.  In  addition,  these  measures  would 
not  be  completely  independent.  For  example,  large 
number  of  page  faults  will  also  result  in  high  I/O  ac¬ 
tivity.  This  also  means  larger  turnaround  time,  more 
number  of  context  switches  for  the  process,  and  higher 
system  time. 

In  the  current  work,  we  look  at  the  means  to  iden¬ 
tify  any  correlations  that  exist  among  these  measures 
(or  features).  When  high  correlations  axe  observed  be¬ 
tween  measures,  some  of  the  measures  could  be  safely 
omitted.  Whether  or  not  such  omissions  will  affect 
intrusion  detection  is  also  a  topic  of  discussion  in  this 
paper. 

In  this  work  we  also  propose  alternate  representa¬ 
tions  for  characterizing  user  behavior.  We  especially 
illustrate  the  use  of  logic  methods  in  arriving  at  rule- 
based  schemes  for  intrusion  detection. 
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3  Data  Mining  Techniques 

Data  mining  is  the  search  for  valuable  information 
in  large  volumes  of  data  [1,  14].  The  data  itself  is 
characterized  by  several  features  (referred  to  as  mea¬ 
sures  in  intrusion  detection).  In  other  words,  the  data 
consists  of  records  with  information  related  to  an  en¬ 
tity  expressed  in  terms  of  characteristics  or  features. 
For  example,  the  credit  information  of  a  credit-card 
holder  may  indicate  the  holder’s  credit  limit,  average 
monthly  charges,  percentage  of  times  the  payment  was 
defaulted,  the  average  annual  earnings,  etc.  One  of  the 
primary  applications  of  data  mining  is  to  predict  the 
unknown  behavior  of  a  potential  customer  based  on 
the  known  historical  behavior  of  other  customers. 

Linear  regression  is  one  of  the  traditional  tech¬ 
niques  used  for  prediction  in  data  mining  [4].  Here, 
given  historical  data  of  say  two  variables,  assuming 
that  one  variable  is  linearly  dependent  on  the  other, 
the  regression  techniques  determine  a  linear  relation¬ 
ship  between  them.  In  other  words,  the  entire  histori¬ 
cal  data  is  now  converted  to  a  simple  linear  equation. 

The  decision  trees  are  also  a  powerful  model  used  in 
data  mining  [4,  14,  13].  They  are  produced  by  several 
techniques  including  classification  and  regression  trees 
and  Chi-squared  automatic  induction.  These  are  par¬ 
ticularly  useful  for  classification.  For  this  reason,  we 
propose  to  use  these  models  to  classify  audit  records 
into  non-intrusive  and  intrusive  classes.  A  decision 
tree  is  expressed  as  a  clear  sequence  of  decision  rules. 
The  rules  themselves  can  be  expressed  as  logic  state¬ 
ments,  in  a  language  such  as  SQL,  and  hence  can  be 
applied  to  new  audit  records  easily. 

Techniques  such  as  neural  nets  and  genetic  algo¬ 
rithms  are  also  used  for  classification  and  prediction 
in  data  mining  [4,  14].  However,  in  the  current  work 
we  do  not  explore  the  application  of  these  techniques 
for  intrusion  detection. 

In  addition,  one  of  the  main  objectives  of  data  min¬ 
ing  techniques  is  to  reduce  the  amount  of  data  that 
need  to  be  processed  when  an  on-line  query  is  received. 
Several  reasons  are  mentioned  for  the  reduction  of 
data.  They  include:  the  expected  time  for  inducing 
a  solution  may  be  too  long  or  the  time  to  read  the 
data  from  the  database  may  be  too  large.  Different 
parameters  associated  with  a  record  of  interest  in  the 
database  are  referred  to  as  features.  Some  of  the  op¬ 
erations  suggested  for  data  reduction  are:  (i)  reduce 
number  of  features,  (ii)  reduce  the  number  of  records 
to  be  processed,  and  (iii)  reduce  the  number  of  val¬ 
ues  for  a  feature  (also  smoothing).  In  the  proposed 
work,  we  concentrate  on  the  first  method — reduce  the 
number  of  features  to  be  examined. 


4  Methods  for  feature  reduction 

One  of  the  main  objectives  of  this  paper  is  to  sug¬ 
gest  methods  to  reduce  data  that  needs  to  be  main¬ 
tained  and  processed  for  intrusion  detection.  One 
method  of  data  reduction  is  reduction  of  the  features 
or  parameters  collected  in  each  audit  record.  Here, 
we  discuss  some  feature  reduction  techniques  and  how 
they  can  be  effective  in  the  reduction. 

The  objective  of  feature  reduction  is  to  determine 
a  subset  of  features  which  best  represent  the  behavior 
of  a  user  as  represented  by  the  audit  records.  Obvi¬ 
ously  the  reduced  subset  should  be  sufficient  to  detect 
any  intrusions  in  the  system.  In  this  section,  we  dis¬ 
cuss  three  methods  for  feature  reduction:  significance 
test  for  an  individual  feature  (features  that  are  not 
significant  may  be  eliminated),  mutual  significance — 
significance  of  a  pair  of  features  (when  a  feature  is 
present  and  significant,  the  other  one  may  be  re¬ 
dundant,  and  hence  eliminated),  and  logic  methods 
or  rule-based  methods  to  identify  user  characteristics 
(those  features  not  appearing  in  the  rules  may  be  elim¬ 
inated). 

Since  the  main  focus  of  this  paper  is  intrusion  de¬ 
tection,  the  role  of  a  feature  in  an  audit  record  is  to 
help  classifying  it  as  either  intrusive  or  non-intrusive, 
hence  we  use  this  context  in  the  following  sections. 

4.1  Significance  Test  for  a  Feature 

One  of  the  characteristics  that  a  feature  should  sat¬ 
isfy  is  whether  or  not  it  can  significantly  help  in  distin¬ 
guishing  a  non-intrusive  audit  record  from  an  intrusive 
one.  Several  statistical  tests  of  significance  currently 
exist  in  literature  [6,  10].  For  example,  if  we  would 
like  to  determine  whether  or  not  CPU  time  is  a  fea¬ 
ture  of  significance,  we  select  nj  audit  records  which 
are  known  to  be  intrusive  and  n^j  non-intrusive  (or 
normal  behavior)  records.  One  test  of  statistical  sig¬ 
nificance  is  as  follows: 


sig(CPUtime ) 


se(7,  NI) 


|/*Z  ~  l*Nl\ 
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a2(NI) 
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Here,  $e  is  the  variance  of  the  distribution  of  the 
sample  means  (the  standard  error  of  the  sampling  dis¬ 
tribution)  ,  and  a2  is  the  sample  variance  for  each  class. 
The  fi’ s  are  the  means  of  CPU  times  in  the  two  classes. 
Since  the  difference  in  means  will  be  approximately 
normally  distributed  for  large  sample  sizes,  indepen¬ 
dent  of  the  distribution  of  the  samples,  we  can  check 
whether  or  not  sig(C PUtime)  is  significant  at  a  given 
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level  of  significance.  We  illustrate  this  with  an  exam¬ 
ple. 

Suppose  we  selected  200  non-intrusive  and  100  in¬ 
trusive  audit  records.  The  mean  CPU  time  for  the 
non-intrusive  records  is  30  msec  and  40  msec  for  the 
intrusive  records.  The  standard  deviation  for  non- 
intrusive  records  is  20  msec  and  30  msec  for  intru¬ 
sive  class.  So  se(I,NI)=  3.31  and  sig(CPUtime)=3.01. 
If  we  are  testing  this  at  the  0.05  level  of  significance 
(or  95%  confidence) 7  the  critical  value  is  1.96.  Since 
the  computed  sig(CPUtime)  is  larger  than  the  criti¬ 
cal  value,  we  can  conclude  that  CPUtime  may  be  a 
significant  feature  in  distinguishing  an  intrusive  activ¬ 
ity  from  a  non-intrusive  one.  In  fact,  in  this  case  the 
feature  is  even  significant  at  a  0.0026  level  or  99.74% 
confidence  level. 

In  cases  where  the  significance  of  the  feature  is  lower 
than  the  critical  value  at  a  given  confidence  level,  we 
can  say  that  the  feature  is  not  statistically  significant 
in  the  classification  of  an  audit  record.  Hence,  it  can 
probably  be  eliminated. 

4.2  Mutual  significance 

In  the  above  test,  each  feature  is  analyzed  inde¬ 
pendently  and  tested  for  significance.  However,  if  the 
features  are  analyzed  collectively,  then  we  may  obtain 
more  information  about  the  features.  For  example, 
from  the  individual  significance  tests,  if  we  were  to 
determine  that  both  CPU  time  and  I/O  time  are  sig¬ 
nificant  in  detecting  an  intrusion.  Then  we  select  both 
the  features.  However,  if  the  features  are  correlated  to 
each  other,  then  one  of  them  will  suffice  for  intrusion 
detection.  One  of  the  methods  to  detect  mutual  sig¬ 
nificance  is  as  follows: 

1.  Let  fTi  and  /ijv/  be  the  vector  of  feature  means 
for  the  intrusive  and  non-intrusive  sets  of  audit 
records,  respectively.  Let  Covi  and  Cov^j  be 
the  covariance  matrices  for  the  intrusive  and  non- 
intrusive  sets  of  audit  records,  respectively. 

2.  Compute 

Dist=(i?1-iiNi)(Covi+CovNi)~1(ii'i-fiNi)T 

3.  Determine  the  smallest  set  of  features  that  can 
result  in  largest  value  of  Dist . 

Since  determining  optimal  feature  set  may  be  com¬ 
putationally  expensive,  heuristic  procedures  are  sug¬ 
gested  to  achieve  near  optimality.  In  general,  the  best 
set  of  k  independent  features  are  the  k  features  with 
the  largest  values  of  (fij  —  pni)2  /{<?  2i+°%i)  [14]- 

For  example,  if  we  also  considered  the  I/O  time  as  a 
feature  and  the  statistics  for  this  feature  are  as  follows: 
The  mean  I/O  time  for  the  200  non-intrusive  records 


is  400  msec  and  300  msec  for  the  100  intrusive  records. 
The  standard  deviation  for  non-intrusive  records  is  200 
msec  and  150  msec  for  intrusive  cases.  So  se(I,NI)= 
20.61  and  sig(IOtime)=4.85.  If  we  are  testing  this  at 
the  0.05  level  of  significance  (or  95%  confidence),  the 
critical  value  is  1.96.  Since  the  computed  sig(IOtime) 
is  larger  than  the  critical  value,  we  can  conclude  that 
IOtime  may  be  a  significant  feature  in  distinguishing 
an  intrusive  activity  from  a  non-intrusive  one.  In  fact, 
in  this  case  the  feature  is  even  significant  at  a  0.001 
level  or  99.99%  confidence. 

Now,  the  question  is  whether  or  not  both  CPUtime 
and  IOtime  need  to  be  considered  for  classifying  an 
audit  record  as  intrusive  or  non-intrusive,  or  one  of 
them  will  suffice.  Suppose  we  also  computed  the  cor¬ 
relation  coefficients  between  the  two  features  in  the 
intrusion  and  non-intrusion  cases,  and  they  are  found 
to  be  pr= 0.75  and  p^i  =  0.6.  So  the  covariance  in 
these  two  cases  is  given  by  on/j=0.75*30*150==3375. 
Similarly,  couyv/= 0.6*20*200=2400.  The  covariance 
matrices  are  given  by: 


900 

3375 

3375 

22500 

400 

2400 

2400 

40000 

From  here,  distance  measure  can  be  computed  as 
follows: 


Dist 


{[Mi  -  Mni)){C /  +  CmrHMj  -  Mn,)t 


([10  -250]) 
1.10 


1300  5775  ]\  1  f\  10 
5775  62500  \)  \[  -250 


This  is  comparatively  a  small  number  indicating  that 
the  features  are  statistically  close.  We  need  to  perform 
the  same  analysis  for  other  feature  pairs  and  pick  the 
ones  with  large  distance. 

4.3  Logic  Methods 

Given  the  training  data,  if  we  can  convert  the  data 
into  a  set  of  decision  rules  or  a  decision  tree,  then  we 
could  use  the  resulting  form  in  intrusion  detection. 

Consider  the  case  of  decision  rules  [12,  14].  The 
rules  are  represented  as  a  set  of  IF-Then  propositions. 
Each  rule  has  a  conditional  part  and  a  conclusion 
part.  The  conditional  part  is  a  boolean  expression  in 
a  propositional  form.  The  conclusion  is  an  assignment 
of  class  or  value. 

Each  decision  tree  is  a  conjunction  of  true-or-false 
terms.  For  example,  if  the  system  has  observed  that 
whenever  CPU  time  is  higher  than  3  minutes  and  I/O 
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time  is  greater  than  4  minutes,  it  is  an  intrusion,  then 
it  is  represented  as: 

CPUTime  >  3.0  A  IOTime  >  4.0  — » Intrusion  (3) 

In  addition,  if  the  system  observed  that  any  time 
CPU  time  is  higher  than  8  minutes  or  I/O  time  greater 
than  15  minutes  there  is  an  intrusion,  we  can  add  two 
more  rules  to  the  above  set: 

CPUTime  >  8.0  Intrusion  (4) 

IOTime  >  15.0  — »  Intrusion  (5) 

Similarly,  the  system  may  also  infer  similar  rules 
about  the  non-intrusive  or  normal  cases.  For  example, 
if  the  training  data  were  to  indicate  that  in  all  cases 
when  CPU  time  is  less  than  1  minute  and  I/O  time  is 
less  than  2  minutes  there  is  no  intrusion,  then  we  can 
add  another  rule: 

CPUTime  <  2  A  IOTime  <  1  ->  No  intrusion  (6) 

The  size  of  rule  set  depends  on  the  number  of  pa¬ 
rameters  and  the  complexity  of  their  relationship  in 
the  presence  or  absence  of  intrusion  activity. 

The  second  form  of  logic  method  to  represent 
the  intrusive/non-intrusive  behavior  is  decision-tree 
[4,  5,  12,  14].  Decision  trees  are  binary  trees  where 
the  nodes  represent  decisions.  For  example,  since 
CPUTime  >  8  represents  a  case  of  intrusion,  the  root 
node  could  be  this  decision.  Here,  the  branch  with 
the  attribute  “True”  would  lead  to  a  leaf  node  of  type 
“intrusion.”  The  branch  with  the  attribute  “False” 
has  several  alternatives.  One  choice  is  to  have  a  node 
with  the  decision  IOTime  >  15.  We  can  thus  build 
the  decision  tree. 

The  size  of  the  tree  is  a  measure  of  the  complexity 
of  this  algorithm.  To  be  more  precise,  the  depth  of 
the  tree  represents  an  exact  measure  of  the  maximum 
comparisons  (at  the  nodes)  that  need  to  be  made  to 
reach  the  final  decision  of  intrusion  or  non-intrusion 
activity. 

Often,  we  may  encounter  situations  where  the  data 
presented  in  the  training  data  is  weak.  For  example, 
when  CPU  time  and  I/O  time  are  the  only  two  fea¬ 
tures  to  characterize  the  activity  and  if  we  found  a 
record  with  CPUTime=4  and  IOTime=3  to  be  intru¬ 
sive  while  another  one  with  CPUTime=3.9  and  10- 
Time=3.2  to  be  non-intrusive.  Should  these  two  cases 
form  two  nodes  in  the  decision  tree  or  two  rules  in 
the  decision  rules?  Obviously,  if  we  were  to  include 
every  such  case  as  a  node  or  a  rule,  the  tree  (or  the 


set  of  rules)  will  be  quite  large  and  hence  larger  com¬ 
putational  complexity.  Alternatively,  we  can  treat  the 
special  as  an  anamoly  and  ignore  it.  For  example, 
if  10  records  suggest  that  values  with  CPU  time  be¬ 
tween  4.0  and  6.0  and  I/O  time  between  8  and  12 
are  non-intrusive,  but  one  intrusive  record  was  found 
with  CPU  time  —  5.5  and  I/O  time  =  10.5.  Then, 
we  can  either  include  it  as  a  separate  node  or  simply 
ignore  the  latter  record  treating  it  as  an  anmoly.  Or 
it  is  likely  that  the  two  selected  parameters  are  not 
adequate  in  identifying  the  intrusive  cases. 

5  Application  of  Data  Reduction  Tech¬ 
niques  in  Intrusion  Detection 

In  this  section,  we  illustrate  the  efficacy  of  the  logic 
methods  through  examples.  For  easy  readabaility,  we 
describe  the  application  and  its  results  as  a  step-by- 
step  procedure. 

1.  Select  the  number  of  features.  We  selected  the 
following  five  features  (F1-F5)  to  represent  user 
behavior.  These  features  are  a  subset  of  those 
chosen  by  the  NIDES  system  in  their  experimen¬ 
tation  [2,  3]. 

Feature  1  ( Fx ):  User  CPU  Time 
Feature  2  (F2):  System  CPU  time 

Feature  3  (F3):  Character  IO  during  the  ap¬ 
plication  execution 

Feature  4  (F4):  The  integral  of  real  memory 
usage  over  time 

Feature  5  (F5):  Number  of  pages  read  in 
from  the  disk 

2.  Select  the  rules  representing  the  normal  behavior 
(i.e.,  non-intrusive)  behavior  of  the  system.  We 
choose  the  following  for  the  illustration. 


Fi  <  10 

(7) 

i*2  ^  5 

(8) 

F3  <  200 

(9) 

F4  <30 

(10) 

F5  <  700 

(11) 

10  <  Fi  <20A10  <F2  <  15 

(12) 

In  a  practical  situation,  these  rules  are  not  avail¬ 
able.  However,  since  we  need  to  generate  data 
representing  user  behavior,  we  use  these  rules, 
the  rules  will  also  be  used  later  to  verify  the  effi¬ 
cacy  of  the  logic  methods.  An  audit  record  that 
satisfies  any  of  the  above  rules  is  said  to  be  non- 
intrusive  or  genuine.  An  audit  record  that  does 
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1 

Fs  >  699.5 

false:  2 

true:  3 

2 

answer—  1 

3 

Fz  >  199.5 

false:  4 

true:  5 

4 

answers  1 

5 

Fa  >  29.5 

false:  6 

true:  7 

6 

answer—  1 

7 

F2  >  4.5 

false:  8 

true:  9 

8 

answer=  1 

9 

Fx  >  9.5 

false:  10 

true:  11 

10 

answer—  1 

11 

F2  >  10.5 

false:  12 

true:  13 

12 

answer  =  2 

13 

Fi  >  19.5 

false:  14 

true:  15 

14 

Fx  >  10.5 

false:  16 

true:  17 

15 

answer—  2 

16 

answer=  2 

17 

answer—  1 

Table  1:  Rules  derived  from  20,000  audit  records 

not  satisfy  any  of  the  above  six  rules  is  said  to  be 
intrusive. 

3.  Set  limits  for  the  values  of  the  features.  We  set 
the  following  limits. 


0  <  Fi  <  30 

(13) 

0  <  Fi  <  15 

(14) 

0  <  F3  <  400 

(15) 

0  <  Fa  <  60 

(16) 

0  <  Fs  <  1000 

(17) 

4.  Generate  audit  records  by  assigning  random  val¬ 
ues  to  each  of  the  five  features.  The  data  gener¬ 
ated  follow  the  limits  mentioned  above  (eqns.  13- 
17).  We  generated  20,000  audit  records. 

5.  Classify  each  record  as  either  intrusive  or  non- 
intrusive  based  on  the  rules  selected  above.  Out 
of  the  20,000  generated,  19,432  were  found  to  be 
non-intrusive  and  the  rest  568  were  intrusive  type. 

6.  Run  a  program  which  can  look  at  the  training 
data  of  20,000  audit  records  (with  classification) 
and  arrive  at  either  a  decision  tree  or  a  set  of  rules 
for  classification.  We  used  the  programs  dtree 
and  logic  supplied  in  [14].  Table  1  summarizes 
the  decision  tree  obtained. 


1 

Fs  >  699.5 

false:  2 

true:  3 

2 

answer =  1 

3 

Ft  >  29.5 

false:  4 

true:  5 

4 

answer—  1 

5 

F2  >  4.5 

false:  6 

true:  7 

6 

answer =  1 

7 

answer—  2 

Table  2:  Rules  derived  for  the  correlated  data 

The  table  s  to  be  interpreted  as  follows.  The  first 
column  is  the  rule  number.  Rule  1  says  that  if  fea¬ 
ture  5  (jFs)  is  greater  than  699.5,  then  go  to  rule 
3;  otherwise  go  to  rule  2.  In  fact,  rule  2  says  that 
answer=l  or  that  the  audit  record  that  is  being 
analyzed  corresponds  to  class  1.  In  our  case,  class 
1  corresponds  to  non-intrusive  audit  records.  In 
other  words,  when  Fs  <  699.5,  an  audit  record 
can  be  automatically  classified  as  a  non-intrusive 
class.  This  matches  with  our  original  data  gener¬ 
ation  rules  (eqn.  7-12).  When  feature  5  is  greater 
than  699.5,  we  go  to  rule  3  which  further  com¬ 
pares  if  Fz  >  199.5. 

Since  the  rules  derived  from  the  audit  data 
through  logic  methods  match  those  of  data  gen¬ 
eration,  we  can  conclude  that  these  methods  were 
quite  effective  in  intrusion  behavior  characteriza¬ 
tion. 

In  the  above  example,  we  chose  all  independent 
values  for  the  features.  Suppose  we  were  to  choose 
some  dependencies  between  the  feature  values.  In 
particular,  if  Fi  =  2  *  F2+random(0,5)  and  F5  = 
2.5*F3-brandom(0,50),  then  clearly  there  is  a  correla¬ 
tion  between  the  features.  When  data  was  generated 
with  these  values,  we  obtained  17861  non-intrusive 
records  and  2139  intrusive  type.  When  the  logic  meth¬ 
ods  were  run  on  the  data,  we  obtained  the  rules  for 
classification  shown  in  Table  2. 

From  Table  2,  we  notice  that  only  features  2,  4,  and 
5  were  considered  in  the  decision  process.  So  the  sys¬ 
tem  was  able  to  infer  the  correlation  between  features 
1  and  2  and  hence  eliminated  feature  1.  Similarly  it 
inferred  the  correlation  between  features  3  and  5  and 
eliminated  feature  3.  Thus,  we  need  only  features  2, 
4,  and  5  to  detect  intrusion.  Thus  the  data  size  is 
reduced.  If  we  do  the  significance  tests  on  these  fea¬ 
tures,  as  described  in  Section  4.1,  we  get  the  results 
of  Table  3. 

From  this  table,  it  is  clear  that  all  features  are  sig¬ 
nificant.  This,  however,  does  not  convey  the  corre- 
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Feature 

Significance 

Fi 

39.2 

Fo 

40.2 

f3 

130.4 

f4 

72.5 

Fs 

130.6 

Table  3:  Significance  of  different  features 


Fi 

f2 

f3 

F, 

^5 

Fi 

1.0 

0.99 

-0.11 

-0.06 

-0.11 

f2 

0.99 

1.0 

-0.11 

-0.06 

-0.11 

f3 

-0.11 

-0.11 

1.0 

-0.14 

0.999 

Fi i 

-0.06 

-0.06 

-0.14 

1.0 

-0.14 

f5 

-0.11 

-0.11 

0.999 

-0.14 

1.0 

Table  4:  Correlation  coefficients  for  Non-intrusive  au¬ 
dit  data 

lation  information  among  the  features.  The  mutual 
significance  of  the  features  is  evident  when  we  look  at 
the  correlation  features,  for  example.  The  correlation 
matrix  for  the  above  data  is  given  in  Tables  4  and  5. 

From  the  correlation  data,  not  surprisingly,  we  can 
observe  that  features  1  and  2  are  highly  correlated. 
Similarly,  features  3  and  5  are  also  highly  correlated. 
Hence,  we  can  reduce  the  five  features  of  the  audit 
record  to  just  three  features. 

If  we  were  to  apply  the  distance  metric  ( dist )  dis¬ 
cussed  in  section  4.2,  we  would  arrive  at  the  same 
conclusion. 

6  Effect  of  Data  Deduction  on  Intru¬ 
sion  Detection 

While  the  data  reduction  techniques  may  help  in 
reducing  the  size  of  the  audit  record  data,  the  main 
concern  is  one  of  false  alarms  or  missed  intrusion  de- 


Fi 

f2 

f3 

Fi 

Fs 

Fi 

1.0 

0.97 

-0.03 

-0.01 

-0.03 

f2 

0.97 

1.0 

-0.03 

-0.02 

-0.03 

f3 

-0.03 

-0.03 

1.0 

-0.01 

0.99 

Fi 

-0.01 

-0.02 

-0.01 

1.0 

-0.01 

f5 

-0.03 

-0.03 

0.99 

-0.01 

1.0 

Table  5:  Correlation  coefficients  for  Intrusive  audit 
data 


tections.  In  other  words,  we  need  to  address  the  issue 
the  loss  (if  any)  in  intrusion  detection  capability  of  the 
system  when  we  apply  the  data  reduction  techniques. 

For  example,  consider  the  case  with  correlated  fea¬ 
tures  discussed  above.  Let  us  remove  features  1  and  3 
from  the  audit  record.  The  next  question  we  need  to 
deal  with  is  the  set  of  rules  for  intrusion  detection. 

1.  Consider  the  rule  E3  <  200.  Since  we  determined 
that  F3  and  are  correlated,  we  need  to  find 
a  relationship  between  them.  If  we  were  to  run 
a  linear  regression  for  F 5  in  terms  of  F3 ,  we  find 
that  F$  =  2.5*F3+25.  In  other  words,  we  need  to 
translate  the  F3  <  200  as  F5  <  562.5.  However, 
since  the  F5  <  700  rule  already  covers  this,  we 
can  eliminate  the  F3  rule  completely. 

2.  Now  consider  the  rule  <  10.  Once  again  using 
a  linear  regression,  we  can  determine  that  2q  = 
2  *  F2  +  2.5.  Hence,  the  rule  may  be  rewritten  in 
terms  of  F2  as  F2  <  3.75.  Once  again,  the  original 
rule  F2  <  5  already  covers  this.  So  we  can  drop 
the  rule. 

3.  Now,  we  need  to  consider  the  rule  10  <  Fi  < 
20  A  10  <  F2  <  15.  Once  again,  using  the  linear 
regression  relationship  derived  above  (  iq  =  2  * 
F2  +  2.5)  we  can  rewrite  it  as  3.75  <  F2  <  8.75  A 
10  <  F2  <  15.  Since  the  two  ranges  for  F2  do  not 
overlap,  we  can  safely  eliminate  this  rule  also. 

Thus,  the  new  set  of  rules  for  intrusion  detection 
cure 


i*2  <  5 

(18) 

Fi  <  30 

(19) 

Fs  <  700 

(20) 

When  we  ran  the  audit  records  under  these  rules, 
we  found  that  all  17861  non-intrusive  records  were 
correctly  identified  as  non-intrusive  class.  The  2139 
intrusive  records  were  also  classified  as  intrusive.  In 
other  words,  there  was  no  loss  of  information  due  to 
the  reduction  of  features  from  5  to  3. 

However,  we  need  to  understand  the  importance  of 
either  rerunning  the  logic  methods  to  determine  the 
new  rules  or  to  modify  the  original  rules  by  incorporat¬ 
ing  the  relationships  between  the  eliminated  features 
and  the  existing  features. 

6,1  Multi-dependency  relationships 

Suppose,  the  relationships  among  the  features  was 
not  one-to-one  as  in  the  above  example,  but  involve 
multiple  features.  For  example,  if  we  have  the  follow¬ 
ing  relationships  Fx  =  1.5  *  F2  4-  0.5  *  F4-f  random(0,5) 
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1 

F3  >  199.5 

false:  2 

true:  3 

2 

answers  1 

3 

F5  >  699 

false:  4 

true:  5 

4 

answer=  1 

5 

F2  >  4.5 

false:  6 

true:  7 

6 

answer=  1 

7 

answer =  2 

Table  6:  Rules  derived  for  the  multiply  correlated  data 

and  F3  =  5*F4  +  3*Fi+F24*random(50).  When  audit 
records  were  generated  under  these  conditions,  with 
the  original  rules,  we  obtained  19665  non-intrusive 
type  and  335  intrusive  type  records.  If  we  were  to  elim¬ 
inate  two  of  the  five  features  from  the  audit  records, 
then  the  original  rules  also  need  to  be  changed  ac¬ 
cordingly.  When  we  applied  the  logic  methods  on  this 
data,  we  obtained  the  rules  of  Table  6. 

Once  again,  when  the  data  was  validated  with  the 
new  rules  and  features  1  and  4  removed  from  the  audit 
records,  we  found  that  the  system  correctly  identified 
all  19665  non-intrusive  records  as  non-intrusive  and 
the  335  records  as  intrusive.  Once  again,  there  was  no 
loss  of  information  due  to  the  reduction  in  the  number 
of  features. 

6.2  Non-linear  dependencies 

So  far  we  had  considered  only  linear  relationships 
among  the  features.  Suppose  there  were  to  be  a  non¬ 
linear  relationship  among  the  features.  For  example, 
let  F5  =  F4  *  F2  +  Fi  4-  random  (100).  When  we  gener¬ 
ated  audit  data  with  this  relation,  we  obtained  19845 
non-intrusive  records  and  155  intrusive  records.  When 
logic  methods  were  employed  on  the  new  data  set,  we 
obtained  the  rules  in  Table  7. 

When  we  checked  the  input  records  with  the  above 
rules,  the  system  classified  19745  of  the  19845  records 
(99.5%)  non-intrusive.  However  the  remaining  0.5% 
non-intrusive  were  falsely  classified  as  intrusive.  This 
would  correspond  to  false  alarms.  Out  of  the  155  in¬ 
trusive  records,  147  or  95.5%  were  correctly  classified 
as  intrusive.  However,  the  remaining  4.5%  were  clas¬ 
sified  as  non-intrusive.  But  the  deterioration  in  per¬ 
formance  is  acceptable  in  most  cases  when  the  cor¬ 
responding  saving  in  processing  and  storage  is  taken 
into  account. 

From  these  examples,  we  can  conclude  that  the 
logic  methods  are  quite  effective  in  reducing  features 
and  arriving  at  a  set  of  rules  based  on  audit  record 
data.  However,  one  needs  to  be  cautious  in  applying 
the  technique  as  it  may  lead  to  a  small  percentage  of 


1 

F5  >  699.5 

false:  2 

true:  3 

2 

answer =  1 

3 

Ft  >  19.5 

false:  4 

true:  5 

4 

F3  >  232 

false:  6 

true:  7 

5 

F3  >  199.5 

false:  8 

true:  9 

6 

answer=  1 

7 

Fi  >  10.5 

false:  10 

true:  11 

8 

answer =  1 

9 

answer=  2 

10: 

Fi  >  9.5 

false:  12 

true:  13 

11: 

answer—  1 

12: 

answer  =  1 

13: 

answer =  2 

Table  7:  Rules  derived  for  the  non-linearly  correlated 
data 

incorrect  classifications.  This  was  especially  so  when 
non-linear  correlation  between  features  was  present. 

7  Conclusion 

While  the  area  of  data  mining  is  rich  with  tech¬ 
niques  to  reduce  time  for  on-line  processing  of  records, 
intrusion  detection  in  computer  system  requires  tools 
to  reduce  its  time  in  detecting  possible  intrusions.  In 
the  current  work,  we  attempted  to  illustrate  some  of 
the  data  reduction  techniques  that  may  be  effectively 
used  for  intrusion  detection  without  compromising  se¬ 
curity.  We  have  especially  focussed  on  statistical  tech¬ 
niques  to  test  individual  significance  and  mutual  sig¬ 
nificance,  and  logic  based  methods  such  as  decision 
trees.  The  preliminary  results  are  encouraging.  In  the 
absence  of  real-data,  we  used  simulated  data  to  show 
the  efficacy  of  the  techniques. 

In  the  future  work,  we  propose  to  test  these  meth¬ 
ods  on  real  audit  record  data.  We  also  propose  to  test 
it  on  data  when  millions  of  data  records  are  available. 
In  addition,  we  propose  to  combine  the  techniques  of 
intrusion  detection  techniques  such  as  NIDES  with 
those  of  the  data  mining  to  reduce  the  on-line  pro¬ 
cessing  time  for  intrusion  detection. 
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ABSTRACT:  Current  approaches  to  access  control  on  Web  servers  do  not  scale 
to  enterprise-wide  systems,  since  they  are  mostly  based  on  individual  users. 
Therefore,  we  were  motivated  by  the  need  to  manage  and  enforce  the  strong 
access  control  technology  of  RBAC  in  large-scale  Web  environments.  RBAC  is 
a  successful  technology  that  will  be  a  central  component  of  emerging  enterprise 
security  infrastructures.  Cookies  can  be  used  to  support  RBAC  on  the  Web, 
holding  users’  role  information.  However,  it  is  insecure  to  store  and  transmit 
sensitive  information  in  cookies.  Cookies  are  stored  and  transmitted  in  clear 
text,  which  is  readable  and  easily  forged. 

In  this  paper,  we  describe  an  implementation  of  Role-Based  Access  Control 
with  role  hierarchies  on  the  Web  by  secure  cookies.  Since  a  user’s  role  informa¬ 
tion  is  contained  in  a  set  of  secure  cookies  and  transmitted  to  the  corresponding 
Web  servers,  these  servers  can  trust  the  role  information  in  the  cookies  after 
cookie-verification  procedures  and  use  it  for  role-based  access  control.  In  our 
implementation,  we  used  CGI  scripts  and  PGP  (Pretty  Good  Privacy)  to  pro¬ 
vide  security  services  to  secure  cookies.  The  approach  is  transparent  to  users 
and  applicable  to  existing  Web  servers  and  browsers. 

KEYWORDS:  Cookie,  Role-Based  Access  Control  (RBAC),  WWW  Security 


1  Introduction 

WWW  is  commonplace.  Increased  integration  of  Web,  operating  system,  and  database 
system  technologies  will  lead  to  continued  reliance  on  Web  technology  for  enterprise  com¬ 
puting.  However,  current  approaches  to  access  control  on  Web  servers  are  mostly  based  on 
individual  users;  therefore,  they  do  not  scale  to  enterprise-wide  systems. 

A  successful  marriage  of  the  Web  and  a  strong  and  efficient  access  control  technology  has 
potential  for  considerable  impact  on  and  deployment  of  effective  enterprise-wide  security  in 
large-scale  systems.  Role-based  access  control  (RBAC)  [San98]  is  a  promising  technology 
for  managing  and  enforcing  security  in  large-scale  enterprise-wide  systems,  and  it  will  be  a 
central  component  of  emerging  enterprise  security  infrastructures.  We  were  motivated  by 
the  need  to  manage  and  enforce  the  strong  access  control  technology  of  RBAC  in  large-scale 
Web  environments. 

To  support  RBAC  on  the  Web,  we  chose  a  relatively  mature  technology,  cookies  - 
widely  used  on  the  Web  -  and  have  extended  it  for  our  purpose.  Cookies  were  invented 
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to  maintain  continuity  and  state  on  the  Web  [KM97,  KM98].  Cookies  contain  strings  of 
text  characters  encoding  relevant  information  about  the  user.  Cookies  are  sent  to  the  user’s 
memory  via  the  browser  while  the  user  is  visiting  a  cookie-using  Web  site,  and  are  stored 
on  the  user’s  hard  disk  after  the  browser  is  closed.  The  Web  server  gets  those  cookies  back 
and  retrieves  the  user’s  information  from  the  cookies  when  the  user  later  returns  to  the 
same  Web  site  or  domain.  The  purpose  of  a  cookie  is  to  acquire  information  and  use  it 
in  subsequent  communications  between  the  Web  server  and  the  browser  without  asking  for 
the  same  information  again.  Often  a  Web  server  sets  a  cookie  to  hold  a  pointer,  such  as  an 
identification  number,  as  a  user-specific  primary  key  of  the  information  database  maintained 
in  the  server.  Technically,  it  is  not  difficult  to  make  a  cookie  carry  relevant  information.  For 
instance,  a  merchant  Web  server  could  use  a  cookie  containing  the  user’s  name  and  credit 
card  number.  This  is  convenient  for  users,  since  they  do  not  have  to  read  lengthy  numbers 
from  their  caxds  and  key  these  in  for  every  transaction.  However,  it  is  not  safe  to  store 
and  transmit  this  sensitive  information  in  cookies  because  cookies  are  insecure.  Cookies 
are  stored  and  transmitted  in  clear  text,  which  is  readable  and  easily  forged.  Therefore,  we 
should  render  secure  cookies  to  carry  and  store  sensitive  data  in  them. 

We  will  provide  secure  cookies  with  three  types  of  security  services:  authentication, 
integrity,  and  confidentiality.  Authentication  services  verify  the  owner  of  the  cookies.  In¬ 
tegrity  services  protect  cookies  against  the  threat  that  the  contents  of  the  cookies  might 
be  changed  by  unauthorized  modification.  Finally,  confidentiality  services  protect  cook¬ 
ies  against  the  values  of  the  cookies  being  revealed  to  an  unauthorized  entity.  Details  for 
these  techniques  have  varying  degrees  of  security  and  convenience  for  users  and  system 
administrators1 . 

In  this  paper,  we  will  describe  how  we  implemented  RBAC  with  role  hierarchy  [FCK95, 
SCFY96]  on  the  Web  using  the  secure  cookies.  To  provide  security  services  to  secure  cookies, 
we  used  CGI  scripts  and  the  PGP  (Pretty  Good  Privacy)  package,  which  are  already  in 
widespread  current  use. 

The  rest  of  this  paper  is  organized  as  follows.  First,  in  Section  2,  we  describe  the 
technologies  most  relevant  to  our  work,  such  as  RBAC,  cookies,  and  PGP.  In  Section  3,  we 
describe  security  threats  to  cookies,  and  how  to  design  secure  cookies  to  support  RBAC  on 
the  Web.  In  Section  4,  we  describe  how  we  actually  implemented  RBAC  on  the  Web  by 
secure  cookies,  using  CGI  scripts  and  PGP  on  an  existing  Web  server.  Section  5  gives  our 
conclusions. 


2  Related  Technologies 

2.1  Role-Based  Access  Control  (RBAC) 

Role-based  access  control  (RBAC)  [San98]  has  rapidly  emerged  in  the  1990s  as  a  promising 
technology  for  managing  and  enforcing  security  in  large-scale  enterprise-wide  systems.  The 

lFor  secure  communications  on  the  Web,  we  may  consider  using  other  existing  technologies,  such  as, 
SHTTP  (Secure  HTTP  [RS98,  SR98])  and  SSL  (Secure  Socket  Layer  [WS96]).  However,  these  technologies 
cannot  solve  the  stateless  problem  of  HTTP.  Furthermore,  none  of  these  can  prevent  end-system  threats  to 
cookies. 
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basic  notion  of  RBAC  is  that  permissions  are  associated  with  roles,  and  users  are  assigned 
to  appropriate  roles.  This  greatly  simplifies  security  management. 

A  role  is  a  semantic  construct  forming  the  basis  of  access  control  policy.  With  RBAC, 
system  administrators  can  create  roles,  grant  permissions  to  those  roles,  and  then  assign 
users  to  the  roles  on  the  basis  of  their  specific  job  responsibilities  and  policy.  Therefore, 
role-permission  relationships  can  be  predefined,  which  makes  it  simple  to  assign  users  to  the 
predefined  roles.  Without  RBAC,  it  is  difficult  to  determine  what  permissions  have  been 
authorized  for  what  users. 

RBAC  is  a  promising  alternative  to  traditional  discretionary  and  mandatory  access  con¬ 
trols,  and  ensures  that  only  authorized  users  are  given  access  to  certain  data  or  resources. 
It  also  supports  three  well-known  security  policies:  data  abstraction,  least-privilege  assign¬ 
ment,  and  separation  of  duties. 

2.2  Cookies 

At  present,  there  are  many  browsers  that  support  cookies,  including  Netscape,  MS  Internet 
Explorer,  GNNWorks,  NetCruiser  and  OmniWeb.  Cookies  have  been  used  for  many  pur¬ 
poses  on  the  Web,  such  as  selecting  display  mode  (e.g.,  frames  or  text  only),  shopping  cart 
selections,  and  carrying  names,  passwords,  account  numbers,  or  some  other  bits  of  identify¬ 
ing  data  on  the  user’s  machine.  Although  there  are  many  ways  to  use  cookies  on  the  Web, 
the  basic  process  and  the  contents  of  cookies  are  similar.  The  detailed  cookie  specifications 
are  available  in  [KM97,  KM98]. 

Whenever  a  browser  sends  an  HTTP  request  for  a  URL  to  a  Web  server,  only  those 
cookies  relevant  to  that  server  will  be  sent  by  the  browser.  If  the  server  finds  any  cookies 
that  are  related  to  the  server,  those  cookies  are  used  during  this  communication  between 
the  browser  and  the  server.  However,  if  the  server  does  not  find  any  cookies  specified  for 
it,  either  that  server  does  not  use  cookies  in  the  communication  or  the  server  creates  new 
cookies  for  subsequent  communication  between  the  browser  and  the  server. 

Web  servers  may  update  the  contents  of  their  cookies  for  any  specific  circumstance. 
The  cookie-issuer  is  not  important  for  cookie  validation.  In  other  words,  a  server  can  create 
cookies  for  other  servers  in  the  domain.  This  is  an  important  aspect  of  cookies  that  will  be 
used  in  our  implementations  described  in  Section  4. 

2.3  Pretty  Good  Privacy  (PGP) 

PGP  (Pretty  Good  Privacy),  a  popular  software  package  originally  developed  by  Phil  Zim- 
mermann,  is  widely  used  by  the  Internet  community  to  provide  cryptographic  routines  for 
e-mail,  file  transfer,  and  file  storage  applications  [Zim95].  A  proposed  Internet  standard 
has  been  developed  [CDFT98],  specifying  use  of  PGP.  It  uses  existing  cryptographic  al¬ 
gorithms  and  protocols  and  runs  on  multiple  platforms.  It  provides  data  encryption  and 
digital  signature  functions  for  basic  message  protection  services. 

PGP  is  based  on  public-key  cryptography.  It  defines  its  own  public-key  pair  management 
system  and  public-key  certificates.  The  PGP  key  management  system  is  based  on  the 
relationship  between  key  owners,  rather  than  on  a  single  infrastructure  such  as  X.509. 
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Basically,  it  uses  RSA  for  the  convenience  of  the  public-key  cryptosystem,  message  digests 
(MD5,  IDEA)  for  the  speed  of  process,  and  Diffie-Hellman  for  key  exchange.  The  updated 
version  supports  more  cryptographic  algorithms. 

Even  though  the  original  purpose  of  PGP  is  to  protect  casual  e-mail  between  Internet 
users,  we  decided  to  use  the  PGP  package.  The  package  is  already  widely  used  and  satisfies 
our  requirements,  in  conjunction  with  Web  servers  via  CGI  scripts  for  our  implementation 
to  protect  cookies.  These  cookies  have  role  information  of  the  user. 


3  Secure  Cookies 

3.1  Security  Threats  to  Cookies 

We  distinguish  three  types  of  threats  to  cookies:  network  security  threats ,  end-system  threats 
and  cookie-harvesting  threats .  Cookies  transmitted  in  clear  text  on  the  network  are  suscep¬ 
tible  to  snooping  (for  subsequent  replay)  and  to  modification  by  network  threats.  Network 
threats  can  be  foiled  by  use  of  the  Secure  Sockets  Layer  (SSL)  protocol  [WS96]  which  is 
widely  deployed  in  servers  and  browsers.2  However,  SSL  can  only  secure  cookies  while  they 
are  on  the  network.  Once  the  cookie  is  in  the  browser’s  end  system  it  resides  on  the  hard 
disk  or  memory  in  clear  text.  Such  cookies  can  be  trivially  altered  and  can  be  easily  copied 
from  one  computer  to  another,  with  or  without  connivance  of  the  user  on  whose  machine 
the  cookie  was  originally  stored.  We  call  this  the  end-system  threat.  The  ability  to  alter 
cookies  allows  users  to  forge  authorization  information  in  cookies  and  to  impersonate  other 
users.  The  ability  to  copy  cookies  makes  such  forgery  and  impersonation  all  the  easier. 
Additionally,  if  an  attacker  collects  cookies  by  impersonating  a  site  that  accepts  cookies 
from  the  users  (who  believe  that  they  axe  communicating  with  a  legitimate  Web  server), 
later  he  can  use  those  harvested  cookies  for  all  other  sites  that  accept  those  cookies.  We 
call  this  the  cookie-harvesting  threat.  These  attacks  are  all  relatively  easy  to  carry  out  and 
certainly  do  not  require  great  hacker  expertise. 

3.2  Designing  Secure  Cookies  for  RBAC  on  the  Web 

In  this  subsection,  we  describe  how  to  transform  regular  cookies  -  which  have  zero  security 
-  into  secure  cookies,  which  provide  the  classic  security  services  against  the  three  types  of 
threats  to  cookies  (described  in  the  previous  subsection). 

Secure  cookies  provide  three  types  of  security  services:  authentication ,  integrity ,  and 
confidentiality  services.  Selection  of  the  kinds  and  contents  of  secure  cookies  depends  on 
applications  and  a  given  situation.  However,  at  least  one  authentication  cookie  and  the 
SeaLCookie  -  which  provides  the  integrity  service  to  the  cookies  -  must  be  used  with  other 
cookies  to  frame  basic  security  services,  regardless  of  applications. 

Figure  1  shows  a  set  of  secure  cookies  that  we  will  create  and  use  for  RBAC  on  the 
Web.  The  Name-Cookie  contains  the  user’s  name  (e.g.,  Alice),  and  the  Role-Cookie  holds 

2 Iel  many  cases  due  to  export  restrictions  from  USA  only  weak  keys  (40  bits)  are  supported,  but  SSL 
technology  is  intrinsically  capable  of  very  strong  protection  against  network  threats. 
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Figure  1:  A  Set  of  Secure  Cookies  for  RBAC  on  the  Web 


the  user’s  role  information  (e.g.,  Director).  The  Life-Cookie  is  used  to  hold  the  lifetime 
of  the  secure-cookie  set  in  its  Cookie-Value  field  and  enables  the  Web  server  to  check  the 
integrity  of  the  lifetime  of  the  secure-cookie  set.  To  protect  these  cookies  from  possible  at¬ 
tacks,  we  will  use  IP -Cookie,  Pswd_Cookie,  and  Seal-Cookie.  Authentication  cookies  (i.e., 
IP  .Cookie  and  Pswd-Cookie)  verify  the  owner  of  the  cookies  by  comparing  the  authentica¬ 
tion  information  in  the  cookies  to  those  coming  from  the  users.  The  IP -Cookie  holds  the 
IP  number  of  the  user’s  machine,  and  the  Pswd-Cookie  holds  the  user’s  encrypted  pass¬ 
words.  This  confidentiality  service  protects  the  values  of  the  cookies  from  being  revealed 
to  unauthorized  entity.  In  our  implementation,  we  used  the  IP -Cookie  and  Pswd-Cookie 
together  to  show  the  feasibility,  but  only  one  of  those  authentication  cookies  can  be  used  to 
provide  the  authentication  service.  The  choice  of  an  authentication  cookie  depends  on  the 
situation.3  Finally,  the  Seal-Cookie  -  which  has  the  digital  signature  of  the  cookie-issuing 
server  on  the  secure  cookie  set  -  supports  integrity  service,  protecting  cookies  against  the 
threat  that  the  contents  of  the  cookies  might  be  changed  by  unauthorized  modification. 

There  axe  basically  two  cryptographic  technologies  applicable  for  secure  cookies:  public- 
key-based  and  secret-key-based  solutions.  In  our  implementation,  we  use  the  public-key- 
based  solution  for  security  services  provided  by  a  PGP  package  via  CGI  scripts.  In  the  next 
section,  we  will  describe  secure  cookie  creation,  verification,  and  use  of  the  role  information 
in  the  Role-Cookie  for  RBAC  with  role  hierarchies,  in  turn. 

3It  is  also  possible  for  authentication  to  be  based  on  use  of  RADIUS  [RRSW97],  Kerberos  [SNS88,  Neu94], 
and  similar  protocols.  Our  focus  in  this  work  is  on  techniques  that  make  secure  cookies  self-sufficient  rather 
than  partly  relying  on  other  security  protocols,  which  is  always  possible. 
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Figure  2:  A  Schematic  of  RBAC  on  the  Web 


4  RBAC  Implementation  by  Secure  Cookies 

Figure  2  shows  a  schematic  of  RBAC  on  the  Web.  The  role  server  has  user-role  assignment 
information  for  the  domain.  After  a  successful  user  authentication,  the  user  receives  his  or 
her  assigned  roles  in  the  domain  from  the  role  server.  Later,  when  the  user  requests  access 
to  a  Web  server  with  the  assigned  roles  in  the  domain,  the  Web  server  allows  the  user  to 
execute  transactions  based  on  the  user’s  roles  instead  of  identity.  The  Web  servers  may 
have  role  hierarchies  or  constraints  based  on  their  policies. 

However,  how  can  the  Web  servers  trust  the  role  information  presented  by  users?  For 
instance,  a  malicious  user  may  have  unauthorized  access  to  the  Web  servers  by  using  forged 
role  information.  Therefore,  we  must  protect  the  role  information  from  being  forged  by  any 
possible  attacks  on  the  Web  as  well  as  in  the  end-systems. 

There  can  be  many  possible  ways  to  support  the  above  requirement.  In  this  paper,  as  one 
possible  solution,  we  will  describe  how  to  protect  the  role  information  from  possible  threats 
using  secure  cookies,  and  how  we  implemented  RBAC  (Role-Based  Access  Control)  with 
role  hierarchy  on  the  Web.  Figure  3  shows  how  the  secure  cookies  (including  a  Role.Cookie) 
for  RBAC  axe  created  and  used  on  the  Web.  If  a  user,  let’s  say  Alice,  wants  to  execute 
transactions  in  the  Web  servers  in  an  RBAC-compliant  domain,  she  first  connects  to  the 
role  server  in  the  beginning  of  the  session.  After  the  role  server  authenticates  Alice,  it  finds 
Alice’s  explicitly  assigned  roles  in  the  URA  (User-Role  Assignment  [SP98,  SB97])  database 
and  creates  a  set  of  secure  cookies:  Name_Cookie,  Life_Cookie,  Role.Cookies,  IP_Cookie, 
Pswd_Cookie,  and  Secil-Cookie.  Then,  those  secure  cookies  are  sent  to  and  stored  in  Alice’s 
hard  drive  securely  so  that  Alice  does  not  need  to  go  back  to  the  role  server  to  get  her 
assigned  roles  until  the  cookies  expire.  Namely,  she  can  use  the  roles  in  her  Role_Cookie 
securely  in  the  RBAC-compliant  domain  as  long  as  the  cookies  are  valid. 

When  Alice  requests  access  to  a  Web  server  -  which  has  PRA  (Permission-Role  As- 
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Figure  3:  RBAC  on  the  Web  by  Secure  Cookies 


signment  [SBC+97])  information  -  by  typing  the  server  URL  in  her  browser,  the  browser 
sends  the  corresponding  set  of  secure  cookies  to  the  Web  server:  Name.Cookie,  Life.Cookie, 
Role.Cookies,  IP  .Cookie,  Pswd.Cookie,  and  Seal-Cookie.  The  Web  server  authenticates  the 
owner  of  the  cookies  by  using  the  IP  .Cookie  and  Pswd.Cookie,  comparing  the  value  in  the 
cookies  with  the  values  coming  from  the  user.  The  user’s  passwords  are  encrypted  in  the 
Pswd.Cookie  using  the  Web  server’s  public  key.  The  Web  server  decrypts  the  value  of  the 
Pswd.Cookie  by  using  the  corresponding  key  to  read  the  user’s  passwords.  Finally,  the 
Web  server  checks  the  integrity  of  the  cookies  by  verifying  role  server’s  digital  signature  in 
the  Seal-Cookie  using  the  role  server’s  public  key.  If  all  the  cookies  are  valid  and  verified 
successfully,  the  Web  server  trusts  the  role  information  in  the  Role.Cookie  and  uses  it  for 
RBAC  with  a  role  hierarchy  and  permission-role  assignment  information  in  the  Web  server. 

4.1  Secure  Cookie  Creation 

When  a  user,  Alice,  connects  to  the  role  server  (which  supports  HTTP)  of  the  domain  with 
her  Web  browser,  she  is  prompted  by  the  HTML  form  to  type  in  her  user  ID  and  passwords 
for  the  domain.  We  used  the  POST4  method  to  send  the  information  to  the  role  server 
and  the  ACTION  field  to  specify  our  Cookie-Set  CGI  program  (set-cookie.cgi),  to  which 
the  form  data  is  passed.  Figure  4  is  a  collaborational  diagram  in  UML  (Unified  Modeling 

4The  GET  request  is  very  similar  to  the  POST  except  that  the  values  of  the  form  variable  are  sent  as 
part  of  the  URL.  However,  the  POST  method  sends  the  data  after  all  their  request  headers  have  been  sent 
to  the  server. 
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Language  [BJR98])  style  notation  for  secure  cookie  creation.  This  diagram  shows  how  we 
create  a  set  of  secure  cookies  for  our  implementation  (refer  to  the  left  side  of  Figure  3). 

The  Web  server  receives  the  request  headers,  which  include  the  address  to  the  “set- 
cookie.cgi”  program  on  the  server.  The  server  translates  the  headers  into  environment 
variables  and  executes  the  program.  The  “set-cookie.cgi”  program  first  retrieves  the  user 
ID  and  passwords,  and  the  IP  number  of  the  client  machine  from  the  environment  variable, 
REMOTE.ADDR.  The  program  authenticates  the  user  by  comparing  the  user  ID  and  pass¬ 
words  with  the  ones  in  the  authentication  database.5  It  then  assigns  the  user  to  roles  by 
matching  the  user  ED  and  the  corresponding  roles  from  the  URA  (User-Role  Assignment) 
database. 

Subsequently,  a  subroutine  for  encryption  is  called  to  another  CGI  program  (encrypt. cgi), 
which  uses  PGP  to  encrypt  the  passwords  by  the  cookie-verifying  Web  server’s  public  key. 
These  encrypted  passwords  will  be  stored  in  the  Pswd-Cookie  by  the  “set-cookie.cgi”  pro¬ 
gram.  Then,  the  “set-cookie.cgi”  program  creates  IP  .Cookie,  Pswd-Cookie,  Name-Cookie, 
Life-Cookie,  and  Role-Cookie,  giving  each  cookie  the  corresponding  value:  IP  number  of  the 
client  machine,  encrypted  passwords,  user’s  name,  lifetime  of  the  cookie  set,  and  assigned 
roles. 

To  support  the  integrity  service  of  the  cookies,  the  “set-cookie.cgi”  program  calls  another 
CGI  program  (sign.cgi),  which  uses  PGP  to  sign  on  the  message  digest  with  the  role  server’s 
private  key.  The  “set-cookie.cgi”  then  creates  the  Seal-Cookie,  which  includes  the  digital 
signature  of  the  role  server  on  the  message  digest  of  the  cookies. 

Finally,  the  Web  server  sends  the  HTTP  response  header,  along  with  the  cookies,  back  to 
the  user’s  browser,  and  the  cookies  are  stored  in  the  browser  until  they  expire.  These  secure 
cookies  will  be  verified  and  used  in  the  Web  servers  as  described  in  the  following  subsections. 
Figure  5  is  an  actual  snapshot  of  a  set  of  secure  cookies  from  our  implementation  that  are 
stored  in  the  user’s  machine  after  the  cookies  are  generated  by  the  cookie-issuing  Web 
server.  The  contents  of  the  cookies  exactly  reflect  the  ones  presented  in  Figure  1.  Each 

5  If  the  user  already  has  an  authentication  cookie  in  a  set  of  secure  cookies,  Web  servers  can  use  the 
authentication  cookie  for  user  authentication  instead  of  authentication  databases. 
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Figure  5:  An  Example  of  Secure  Cookies  Stored  in  a  User’s  Machine 


cookie  has  its  corresponding  domain,  flag,  path,  security  flag,  expiration  date,  name,  and 
value.  The  user’s  name,  role,  lifetime  of  the  cookie  set,  IP  number,  encrypted  passwords, 
and  the  digital  signature  of  the  cookie-issuing  Web  server  on  the  cookies  are  stored  in  the 
corresponding  cookies. 

4.2  Secure  Cookie  Verification 

Figure  6  is  a  collaborational  diagram  in  UML  style  notation  for  secure  cookie  verification. 
This  diagram  shows  how  we  verify  (corresponding  to  the  right  side  of  Figure  3)  the  set  of 
secure  cookies  that  we  generated  in  the  previous  subsection  for  our  implementation.  When 
Alice  connects  to  a  Web  server  (which  accepts  the  secure  cookies)  in  an  RBAC-compliant 
domain,  the  connection  is  redirected  to  the  “index.cgi”  program.  The  related  secure  cookies 
are  sent  to  the  Web  server  and  she  is  prompted  by  the  HTML  form  to  type  in  her  user  ID 
and  passwords.  The  “index.cgi”  program  first  uses  the  HTTP.COOKIE  environment,  vari¬ 
able  to  retrieve  the  secure  cookies  (Name-Cookie,  Life.Cookie,  Role_Cookies,  IP_Cookie, 
Pswd_Cookie,  and  SeaLCookie)  for  the  Web  server.  It  then  checks  the  validity  of  all  the 
cookies.  The  two  IP  addresses,  one  from  the  IP  cookie  and  the  other  from  the  environment 
variable,  REMOTE.ADDR,  are  compared.  If  they  are  identical,  then  the  host-based  au¬ 
thentication  is  passed,  and  a  hidden  field  “status”  with  the  value  of  “IP-passed”  is  created 
to  indicate  that  this  stage  was  passed6.  However,  if  the  IP  numbers  are  different,  the  user 

6We  used  a  hidden  field  to  check  the  completion  of  the  previous  stage,  which  is  passed  on  to  the  next 
program.  This  hidden  field  protects  the  pages  from  being  accessed  directly,  skipping  required  verification 
steps,  by  a  malicious  user.  For  example,  without  this  hidden  field,  a  malicious  user  can  access  the  pages 
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Figure  6:  Verifying  Secure  Cookies 


is  rejected  by  the  server. 

When  the  user  submits  her  user  ID  and  passwords  to  the  server,  the  Web  server  trans¬ 
lates  the  request  headers  into  environment  variables,  and  another  CGI  program,  “password- 
ver.cgi,”  is  executed.  We  used  the  POST  method  to  send  the  information  to  the  Web  server 
and  the  ACTION  field  to  specify  the  CGI  program  (password-ver.cgi)  to  which  the  form 
data  are  passed.  The  first  thing  the  “password-ver.cgi”  does  is  to  check  the  hidden  field 
“status”  to  see  if  the  previous  stage  was  successfully  completed.  If  this  is  “IP -passed,” 
the  program  decrypts  the  value  of  the  Pswd_Cookie  (encrypted  user  password)  using  the 
PGP  with  the  Web  server’s  private  key,  since  it  was  encrypted  with  the  Web  server’s  public 
key  by  the  role  server.  The  program  (password-ver.cgi)  then  compares  the  two  passwords: 
one  from  the  user  and  the  other  decrypted  from  the  Pswd_Cookie.  If  they  are  identical, 
then  the  user-based  authentication  is  passed,  and  a  hidden  field  “status”  with  the  value  of 
“password-passed”  is  created  to  indicate  that  this  stage  was  passed.  However,  if  the  two 
passwords  are  different,  the  user  has  to  start  again  by  either  retyping  the  passwords  or 
receiving  new  cookies  from  the  role  server. 

After  the  password  verification  is  completed,  another  CGI  program,  “signature-ver.cgi,” 
is  activated  to  check  the  integrity  of  the  cookies.  Like  the  other  programs,  it  first  checks  the 
value  of  “status”  passed  on  from  the  previous  program,  and  it  proceeds  only  if  it  shows  the 
user  has  been  through  the  password  verification  stage.  If  the  value  is  “password-passed,” 
then  the  program  verifies  the  signature  in  the  Seed-Cookie  with  the  role  server’s  public  key 
using  PGP.  If  the  integrity  is  verified,  it  means  that  the  cookies  have  not  been  altered,  and 
a  hidden  field  “status”  with  the  value  of  “verify-passed”  is  created  to  indicate  that  this 
stage  was  passed  and  forwarded  to  the  final  program,  “rbac.cgi.”  This  program  uses  the 
role  information  in  the  Role-Cookie  for  role-based  access  control  in  the  server  as  described 
in  the  following  subsection.  However,  if  the  signature  verification  is  failed,  the  user  has  to 
start  again  by  receiving  new  cookies  from  the  role  server. 

directly  with  forged  cookies. 
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Figure  7:  An  Example  Role  Hierarchy 


4.3  RBAC  in  the  Web  Server 

After  verifying  all  the  secure  cookies,  the  Web  server  allows  the  user,  Alice,  to  execute 
transactions  based  on  her  roles,  contained  in  the  Role.Cookie,  instead  of  her  identity.  In 
other  words,  the  Web  server  does  not  care  about  the  user’s  identity  for  authorization  pur¬ 
poses.  This  resolves  the  scalability  problem  of  the  identity-based  access  control,  which  is 
being  used  mostly  in  existing  Web  servers.  Furthermore,  the  Web  server  can  also  use  a  role 
hierarchy,  which  supports  a  natural  means  for  structuring  roles  to  reflect  an  organization’s 
lines  of  authority  and  responsibility.  Each  Web  server  may  have  a  role  hierarchy  defferent 
from  that  in  other  servers.  In  our  implementation,  we  used  a  role  hierarchy  in  the  Web 
server,  depicted  in  Figure  7.  The  location  of  RB AC-compliant  Web  servers  is  geographically 
free  from  that  of  the  role  server,  since  cookies  can  be  issued  by  one  Web  server  for  use  by 
others,  regardless  of  their  physical  location. 

If  the  “rbac.cgi”  program  in  Figure  6  receives  the  value,  “verify-passed,”  from  the  previ¬ 
ous  verification  step,  it  means  that  the  cookies  have  successfully  passed  all  the  verification 
stages,  such  as  IP,  passwords,  and  signature  verification.  Therefore,  the  Web  server  can 
trust  the  role  information  in  the  Role-Cookie,  and  uses  it  for  role-based  access  control  in 
the  server. 

Suppose  Alice  has  the  role  DIR7  in  her  Role-Cookie  and  she  wants  to  access  resources 
for  PEI  -  which  require  the  PEI  role  or  roles  senior  to  the  PEI  role  in  the  role  hierarchy 
-  in  a  Web  server.  First,  she  has  to  prove  that  the  cookies  she  is  presenting  are  genuine. 
To  prove  this,  she  has  to  go  through  all  the  verification  steps:  IP,  passwords,  and  signature 
verification.  She  cannot  jump  ahead  or  skip  any  verification  stage,  as  each  program  requires 
a  hidden  field,  “status,”  from  the  previous  stage.  After  the  Web  server  has  successfully 

7 Multiple  roles  can  be  stored  in  a  Role-Cookie. 
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completed  all  the  verification  steps,  the  “rbac.cgi”  program  retrieves  the  role  information, 
DIR,  from  Alice’s  Role-Cookie,  and  shows  all  the  available  roles8  based  on  the  role  hierarchy 
depicted  in  Figure  7.  Since  she  wants  access  to  the  pages  that  require  PEl’s  privilege,  she 
chooses  the  PEI  role  to  activate  it  among  her  available  roles.  Then  she  has  the  permissions 
assigned  to  the  PEI  role  and  the  roles  junior  to  PEI,  such  as  El,  ED  and  E.  Now,  when 
Alice  requests  access  to  a  particular  page  in  the  server,  the  page  checks  if  her  activated  role, 
PEI,  has  permission  to  access  the  page. 

The  user  can  use  any  roles  among  her  available  roles  by  activating  them.  For  instance,  if 
Alice  would  activate  PL1,  then  she  would  be  allowed  to  access  the  pages,  which  require  the 
PEI  role,  since  PL1  is  senior  to  PEI  in  the  role  hierarchy.  However,  if  she  were  to  activate 
El,  then  she  would  not  be  allowed  to  access  the  pages,  since  El  is  junior  to  PEI.  This 
supports  least  privileges,  since  only  those  permissions  required  for  the  tasks  are  turned  on 
by  activating  the  required  role. 

How  then  can  the  Web  server  protect  the  pages  from  being  accessed  by  unauthorized 
users?  Suppose  a  malicious  user,  Bob,  has  the  role  PEI  but  wishes  to  access  pages  that 
require  the  PL1  role.  He  could  change  the  value  of  his  Role_Cookie  so  that  it  has  PL1,  or 
roles  senior  to  PL1.  He  would  go  through  the  password  verification  stages,  since  he  would 
be  able  to  log  in  as  Bob  by  using  his  own  passwords.  However,  when  his  SeaLCookie  is  being 
verified,  there  would  be  a  problem,  as  the  signature  verification  would  fail.  Therefore,  he 
would  not  be  allowed  to  move  beyond  this  stage.  On  the  other  hand,  he  could  try  accessing 
the  pages  directly  by  typing  the  URLs.  This  would  not  be  allowed,  since  each  page  checks 
to  see  if  he  has  activated  the  required  role,  PL1,  or  roles  senior  to  PL1.  In  other  words, 
Bob  is  not  allowed  to  access  the  pages,  which  require  roles  senior  to  his,  because  he  cannot 
activate  the  senior  roles,  which  are  out  of  his  available  role  range. 

As  a  result,  the  Web  server  allows  only  users,  who  have  gone  through  all  the  verifi¬ 
cation  steps  with  the  secure  cookies  (Name_Cookie,  Life_Cookie,  Role_Cookies,  IP_Cookie, 
Pswd-Cookie,  Seal-Cookie),  to  access  the  pages.  This  access  also  is  possible  only  if  the 
users  have  the  required  roles  and  activate  them  among  their  available  roles  based  on  the 
role  hierarchy. 

5  Conclusions 

In  this  paper,  we  have  described  how  we  implemented  RBAC  with  role  hierarchies  on  the 
Web  using  secure  cookies .  To  protect  the  role  information  in  the  cookies,  we  provided 
security  services,  such  as  authentication,  confidentiality,  and  integrity,  to  the  cookies  using 
PGP  and  CGI  scripts  in  the  Web  servers.  The  cookie-issuing  Web  server  creates  a  set  of 
secure  cookies  including  the  user’s  role  information,  and  other  Web  servers  use  the  role 
information  for  RBAC  with  role  hierarchies  after  cookie  verification.  This  access  control 
mechanism  solves  the  scalability  problem  of  existing  Web  servers.  The  use  of  secure  cookies 
is  a  transparent  process  to  users  and  applicable  to  existing  Web  servers  and  browsers. 

8In  this  example,  all  the  roles  from  E  to  DIR  are  available  to  Alice,  since  she  has  the  senior  most  role  in 
the  role  hierarchy. 
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Abstract 

In  this  paper,  we  present  an  enhanced  use  of  RBAC 
features  in  articulating  a  security  policy  for  access 
control  in  medical  database  systems.  The  main  advantage 
of  this  implementation  is  that  it  supports  both  MAC  and 
DAC  features  at  the  same  time;  a  feature  that  has  been 
proved  to  be  necessary  in  healthcare  environments.  The 
eMEDAC  security  policy  that  results  from  the  above 
implementation  provides  an  enhanced  redefinition  of  a 
number  of  mechanisms  of  the  already  known  MEDAC 
security  policy.  The  concept  of  hyper  node  hierarchies  is 
proposed  for  deriving  totally  ordered  security  levels  while 
preserving  the  role  hierarchy  levels  required  satisfying 
particular  administration  needs.  Finally,  a  demonstration 
example  is  given  based  on  the  pilot  implementation  of  the 
proposed  security  policy  in  a  major  Greek  hospital.  The 
advantages  offered  are  related  to  the  efficiency  of  access 
control,  the  flexibility  and  decentralisation  of 
administration,  and  the  storage  savings. 


1.  Introduction 

Until  now,  in  the  key  area  of  access  control  three  major 
categories  of  security  policies  have  been  proposed  that  are 
usually  used  in  computer  systems:  die  discretionary 
policies,  the  mandatory  policies,  and  the  role-based 
policies.  A  recent  well  known  role-based  approach  is 
RBAC  (Role  Based  Access  Control),  which  has  received 
considerable  attention  as  a  promising  way  to  enhance 
traditional  discretionary  (DAC)  and  mandatory  (MAC) 
access  controls. 
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According  to  [16],  an  important  characteristic  of  RBAC 
is  that  by  itself  it  is  policy  neutral.  Furthermore,  the  security 
policy  enforced  in  a  particular  system  could  be  the  net  result 
of  the  appropriate  configuration  and  interactions  of  various 
RBAC  components  (mechanisms).  Another  important 
benefit  of  RBAC  is  the  ability  to  modify  the  security  policy 
to  meet  the  changing  needs  of  an  organization.  However, 
most  of  the  research  work  today,  has  being  focused  on  the 
support  of  the  DAC  philosophv  using  the  RBAC  approach 
([4],  [5],  [14],  [21]). 

The  scope  of  this  paper  is  to  present  an  exploitation  of 
RBAC  features  in  articulating  a  security  policy  for  access 
control  in  medical  database  systems  (where  both  mandatory 
and  discretionary  features  are  needed).  To  achieve  this,  the 
mechanisms  of  the  already  known  MEDAC  security  policy 
have  been  redefined  on  the  basis  of  RBAC  components.  The 
resulting  security  policy  (eMEDAC)  is  an  enhancement  of 
MEDAC  that  offers  significant  advantages,  especially  in 
access  control,  administration  and  storage  requirements 
(with  some  drawbacks  of  additional  computational 
workload). 

2.  The  MEDAC  Security  Policy 

Security  policies  are  sets  of  principles  and  high  level 
guidelines  that  concern  the  design  and  management  of 
access  control  systems  ([2]).  Mechanisms  are  low  level 
software  and  hardware  functions,  which  can  be  configured 
to  implement  a  security  policy  ([15]).  In  general,  there  are 
no  policies  that  are  better  than  others.  This  is  because,  not 
all  systems  have  the  same  protection  requirements.  Policies 
suitable  for  a  given  system  may  not  be  suitable  for  another. 
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The  choice  of  security  policy  depends  on  the  particular 
characteristics  of  the  environment  to  be  protected. 
However,  in  recent  years  there  is  an  increasing  consensus 
that  there  are  legitimate  policies  that  have  aspects  of  both 
mandatory'  and  discretionaiy  security  models.  Role-based 
policies  are  an  example  of  this  fact. 

In  health  care  environments  there  is  a  need  for  a 
security  policy  that  is  able  to  satisfy  all  the  security 
components  (availability,  integrity  and  confidentiality). 
As  has  been  demonstrated  previously  ([7],  [12],  [13]), 
both  DAC  and  MAC  when  used  separately  have  their 
limitations  in  achieving  this.  As  a  result,  we  have 
previously  proposed  a  security  policy  called  MEDAC 
(MEdical  Database  Access  Control)  based  on  both  MAC 
and  DAC  approaches,  that  has  been  proved  to  be  able  to 
satisfy  all  the  needed  security  requirements. 

2.1.  Overview  of  the  Original  MEDAC  Security 
Policy 

The  MEDAC  security  policy  is  based  on  the  Bell- 
LaPadula  model  ([2])  and  takes  advantage  by  utilizing  the 
characteristics  of  discretionaiy,  mandatory  and  role-based 
approaches.  A  detailed  presentation  of  MEDAC  can  be 
found  in  [7],  [11],  [12],  [13].  It  is  based  on  the  following 
principles: 

>  Every  authorized  person  has  the  right  to  access  the 
system.  For  this  reason,  each  user  accessing  directly 
the  system  must  have  an  account  allowing  him  to  log 
into  the  system.  Every  account  is  associated  to  a 
predefined  user  role.  This  user  role  represents  the 
user  task  in  the  application. 

>  Every  user  role  has  a  clearance  level  and  a  category 
set.  The  category  depends  on  the  nature  of  the  user 
role  and  the  data  sets  it  needs  to  access.  The 
clearance  level  of  the  user  role  represents  its 
trustworthiness. 

>  Every  data  set  is  assigned  a  sensitivity  level  and  a 
categoiy  set.  The  sensitivity  level  reflects  its 
sensitivity  depending  on  its  context,  content,  exterior 
factors  or  specific  situations  (e.g.  related  to  sensitive 
cases).  The  category  depends  on  the  use  and  the 
nature  of  the  data  set. 

The  levels  within  a  certain  category  are  completely 
ordered  (hierarchical),  while  the  categories  are  partially 
ordered. 

The  MEDAC  security  policy  is  formed  of  three  layers 
that  every  user  requesting  to  access  the  database  has  to 


Figure  1.  The  MEDAC  model. 


pass  through.  The  MEDAC  model  is  shown  schematically 
in  figure  1.  More  specifically: 

•  First  layer:  In  this  layer,  the  identification  and 
authentication  of  a  particular  user  is  performed  by  the 
security  mechanisms  of  the  host  system.  After  his 
identification,  the  user  activates  a  user  role  from  the  set 
of  roles  that  has  been  assigned  to  him  initially. 

•  Second  layer:  User  roles  in  this  layer  are  permitted  to 
access  the  database  via  a  discretional  access  control. 
Each  user  role  has  the  authorisation  to  see  a  certain 
view  and  to  exercise  just  the  authorised  access  rights. 
The  view  has  been  predefined  depending  on  the  need- 
to-know  requirements  of  the  users  performing  this  role. 

•  Third  layer:  Users  roles  are  required  to  access  the 
database  satisfying  the  multilevel  access  control. 
Depending  on  the  clearance  level  of  the  specific  user 
role,  it  will  be  able  to  access  just  the  part  of  the 
database  which  is  defined  according  to  the  dominance 
relation  (i.e.,  the  sensitivity  level  of  the  information 
which  can  be  read  by  the  user  role  is  less  or  equal  to  its 
clearance  level). 

MEDAC  has  been  implemented  already  in  the  AHEPA 
general  hospital  of  Thessaloniki.  This  experimental 
implementation  has  produced  successful  results  ([12],  [13]). 
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2.2.  Supported  Characteristics  of  the  Major 
Security  Models 

•  ‘DAC’  Characteristics:  Discretionary  controls  are 
supported  in  the  MEDAC  policy  as  a  combination  of 
the  access-matrix  mechanism  and  specialized  views 
that  are  used  to  define  the  sets  of  permitted  types  of 
access  that  can  be  executed  by  specific  user  roles  to 
data  sets.  Schematically,  the  DAC  aspects  of  the 
MEDAC  policy  are  handled  in  the  2nd  layer  of  the 
MEDAC  model  (Figure  1). 

•  ‘MAC’  Characteristics:  In  the  MEDAC  policy  the 
multilevel  model  of  MAC  is  supported.  An 
important  characteristic  of  the  MEDAC  policy  is 
that  mandatory  security  controls  are  used 
additionally  to  the  discretional  security  ones. 
Mandatory  access  control  is  based  on  the  sensitivity 
of  the  personal  and  medical  data  of  patients  in  order 
to  ensure  their  protection  in  a  strict  way  ([9],  [13]). 
Furthermore,  the  use  of  multilevel  security  has  made 
it  possible  to  provide  generalized  explanations 
(cover  stories)  for  unavoidable  observable 
information  that  would  otherwise  lead  to  partial  or 
complete  inference  of  sensitive  information  ([10]). 
Schematically,  the  MAC  aspects  of  the  MEDAC 
policy  are  handled  in  the  3rd  layer  of  the  MEDAC 
model. 

•  ‘RBAC’  Characteristics:  MEDAC  also  partly 
supports  the  RBAC  approach,  mainly  by  means  of 
user  roles  and  the  user  role  hierarchy.  The  use  of  the 
concept  of  user  roles  has  made  it  possible  for  every 
user  to  have  access  just  to  that  part  of  the  application 
he  needs  to  use  in  order  to  perform  his  specific  task 
([10]).  Schematically,  the  RBAC  aspects  of  the 
MEDAC  policy  are  handled  in  the  1“  layer  of  the 
MEDAC  model  (Figure  1).  However,  although 
MEDAC  takes  into  account  the  RBAC  concept,  it 
does  not  utilize  the  RBAC  features  fully,  since  it  has 
been  developed  independently,  before  RBAC  was 
widely  accepted. 

3.  The  Enhanced  MEDAC  Security  Policy 
(eMEDAC) 

3.1.  The  RBAC  Components  Used 

Role-based  policies  allow  the  specification  of 

authorizations  to  be  granted  to  users  on  objects  like  in  the 


discretionary  approach,  together  with  the  possibility  of 
specify  ing  restrictions  on  the  assignment  or  on  the  use  of 
such  authorizations.  They  also  provide  a  classification  of 
users  according  to  the  activities  they  execute.  Analogously, 
a  classification  is  recommended  for  objects  according  to 
their  type  or  to  their  application  area  ([15]). 

RBAC  is  an  emerging  role-based  policy  ([6],  [17],  [18]). 
Role  hierarchies  are  used  in  RBAC  for  structuring  roles  to 
reflect  an  organization's  lines  of  authority  and 
responsibility.  More  powerful  (senior)  roles  are  placed 
toward  the  top  and  less  powerful  (junior)  roles  toward  the 
bottom  of  the  diagrams  representing  them  ([19]).  To  limit 
the  scope  of  inheritance  in  hierarchies,  a  special  kind  of 
roles  is  used,  named  private  roles  ([18]).  Permissions  are 
approvals  of  particular  modes  of  access  to  objects  in  the 
system.  Permissions  are  always  positive  and  confer  on  their 
holder  the  ability  to  perform  an  action  in  the  system  ([19]). 
Constraints  are  another  important  aspect  of  RBAC  and  are 
sometimes  argued  to  be  the  principal  motivation  for  RBAC. 
A  common  example  is  that  of  mutually  exclusive  roles. 
Constraints  are  a  powerful  mechanism  for  enforcing  higher 
level  organizational  policy.  Once  certain  roles  are  declared 
mutually  exclusive,  there’s  less  concern  about  assigning 
individual  users  to  roles  ([19]). 

According  to  [18],  RBAC  provides  a  means  for 
articulating  policy  rather  than  embodying  a  particular 
security  policy.  Hence,  RBAC  could  be  used  for  the 
redefinition  of  mechanisms  of  the  original  MEDAC  security 
policy,  by  extending  its  role-based  concepts  and  replacing 
stored  mandatory  security  labels  with  derived  ones.  In  this 
way  the  enhanced  MEDAC  (eMEDAC)  security  policy 
should  utilize  fully  the  RBAC  features  to  support  the 
changing  administration  needs  of  healthcare  organizations 

3.2.  Overview  of  the  eMEDAC  Model 

The  eMEDAC  model  uses  RBAC  features  that  have  been 
tailored  to  meet  the  specific  needs  of  a  healthcare 
information  system.  In  such  a  context,  the  access-matrix 
could  be  implemented  with  the  RBAC  permission 
mechanism  to  support  the  DAC  features  needed.  In  order  to 
satisfy  the  MAC  requirements  for  accessing  sensitive 
patient  data,  the  role  hierarchy  and  constraint  mechanisms 
are  used  in  the  following  way. 

Because  there  is  a  strong  similarity  between  the  concept 
of  a  security  label  (consisting  of  a  security  level  and  a  set  of 
categories)  and  a  role  ([18]),  security  levels  could  be 
implemented  by  means  of  the  position  (depth)  of  a  role 
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(node)  in  the  hierarchy  and  categories  could  be  derived 
from  the  ancestor  nodes  reached  when  moving  towards 
the  top  of  the  hierarchy.  As  a  result  of  tills,  security  labels 
are  not  stored  but  are  directly  derived  from  the  hierarchy. 

However,  there  is  a  need,  e.g.  for  the  medical  and  the 
ward  activities  of  a  Health  Information  System  (HIS),  to 
protect  in  a  strict  way  the  privacy  of  patient  personal  and 
medical  data  ([9]).  This  requirement  results  in  a  definite 
number  of  required  (mandatory)  security  levels. 
Therefore,  each  role  in  the  hierarchy  is  assigned  to  a 
specific  level  number  that  cannot  exceed  a  predefined 
limit.  This  is  a  constraint  that  dominates  the  construction 
of  hierarchies  and  is  useful  mainly  in  a  decentralized 
access  control  system  (as  discussed  in  more  detail  in 
section  4). 

In  order  to  solve  the  problem  of  assigning  to  a  given 
role  a  level  number  that  is  not  necessarily  equal  to  the 
level  number  of  its  ancestor  minus  one  (e.g.  the  role  is  of 
level  2  and  its  ancestor  is  of  level  4)  we  use  dummy  nodes 
between  the  two  hyper  nodes  in  the  hierarchy. 

Every  hierarchy  has  at  least  one  level  of  initial  nodes 
that  are  assigned  to  the  highest  (or  lowest)  security  level. 
Every  other  node  is  a  descendant  of  its  ancestor  node  and 
is  placed  in  a  different  level.  As  a  result  of  this,  the 
category  set  of  a  node  could  be  the  set  of  all  its  ancestors 
(in  case  they  are  not  dummy  nodes)  that  are  nearest  to  the 
top  of  the  hierarchy  (first  ancestors). 

Until  now  we  assumed  that  each  node  is  assigned  to  a 
different  level  than  its  ancestor  node.  As  a  result,  going 
down  a  level  in  the  hierarchy  the  level  number  is  changed 
by  one.  However,  this  fact  introduces  restrictions  when 
for  example  the  security  lattice  has  depth  five  and  the  role 
hierarchy  has  depth  ten.  To  solve  this  problem  we  propose 
a  special  connection  between  nodes  of  the  same  level, 
named  link. 

To  support  the  above  features  the  concept  of  the  Hyper 
Node  Hierarchy  (HNH)  mechanism  has  been  introduced. 

3.3.  The  Hyper  Node  Hierarchy  Mechanism 

A  Hyper  Node  Hierarchy  (HNH)  is  a  set  of  nodes  and 
connections  (figure  2).  Each  (regular  or  dummy)  node  is 
connected  to  another  node  by  a  branch  or  a  link.  A  branch 
is  the  connection  of  a  node  to  its  ancestor  node  in  the 
above  level  of  the  same  HNH.  Links  are  connections  that 
are  used  between  nodes  of  the  same  level.  A  link  is  used 
in  order  to  specialize  the  inner  structure  (in  the  form  of  a 
sub-hierarchy)  of  a  hyper  node,  by  introducing  its 


',_y  is  a  dummy  node 
— ►  is  a  branch 


--->  is  a  link 

Figure  2.  The  Hyper  Node  Hierarchy  (HNH). 

descendant  starting  from  the  same  level  (otherwise  branches 
could  be  used). 

The  HNH  mechanism  provides  totally  ordered 
hierarchies  and  supports  multiple  inheritance  by  using 
multiple  occurrences  of  the  same  node  (figure  2).  A  formal 
definition  of  the  HNH  mechanism  is  given  below. 

Definition  1:  The  HNH  mechanism: 

■  N,  a  set  of  nodes 

■  C,  a  set  of  connections 

■  HN  czNxC,  each  hyper  node  HN  is  a  double  {.V,  C), 

*  HNH  c  HN  x  HN,  is  a  totally  ordered  hyper  node 
hierarchy. 

•  HN  and  DN,  disjoint  sets  of  (regular)  hyper  nodes  and 
dummy  nodes  respectively, 

■  BC  and  LC,  disjoint  sets  of  branches  and  links 
respectively, 

■  a  node  N  has  a  level  (depth  in  the  hierarchy)  of  number 

i, 

■  BC  :  N,  ->  N'i±i,  branch  is  a  function  mapping  a  node 
to  its  ancestor  node  at  the  above  level, 

■  LC  :  Ni  ->  N'i,  link  is  a  function  mapping  each  node  to 
its  ancestor  (hyper)  node  at  the  same  level. 

The  security  labels  (consisting  of  a  security  level  and  a 
category  set)  are  implemented  in  a  HNH  as  defined  below. 

Definition  2:  Implementation  of  the  security  level  and 
the  category  set  in  a  HNH: 


58 


■  a  hyper  node  H  ,  has  a  security  level  of  number  i, 

■  the  category *  set  of  a  hyper  node  H  ,  is  consisted  of 
all  its  possible  first  ancestors. 

The  HNH  concept  is  used  to  construct  user  role  and 
data  set  hierarchies. 

3.4.  The  User  Role  Hierarchy 

More  specifically,  the  User  Role  Hierarchy  (URH) 
consists  of  a  HNH  having  at  least  one  level  of  hyper 
nodes  with  connection  “All  Users”.  Then,  these  roles  may 
be  specialized  into  one  or  more  levels  of  (senior)  user 
roles. 

The  number  of  levels  in  a  URH  is  predefined 
depending  on  the  granularity  of  the  control  needed  (for 
example  in  military  environments  it  is  considered  to  be 
four,  respectively  for  Unclassified,  Confidential,  Secret, 
and  Top  Secret).  User  roles  placed  on  the  top  of  the  URH 
are  of  lowest  level  (e.g.  1). 

By  its  turn,  the  use  of  links  introduces  new  sub¬ 
hierarchies  where  the  same  procedure  can  be  repeated 
until  the  security  administrator  is  satisfied  that  the 
specialization  achieved  is  enough  for  the  specific 
application.  The  number  of  new  sub-hierarchies  resulting 
from  the  use  of  links  of  hyper  nodes  is  not  predefined, 
allowing  the  security  administrator  the  ability  to  analyze 
any  hyper  node,  reaching  to  any  depth  of  analysis  in  the 
tree,  depending  on  the  special  needs  of  the  application. 
For  example  in  a  specialized  hospital  (e.g.  cancer 
hospital)  the  set  of  user  roles  needed  is  more  sophisticated 
than  in  a  general  hospital.  However,  each  sub-hierarchy 
resulting  from  a  hyper  node  (to  analyze  further  its  inner 
structure)  has  a  predefined  number  of  levels  that  is 
derived  from  the  level  of  the  source  hyper  node.  This  sub- 
hierarchy  cannot  include  levels  lower  than  the  level  of  the 
source  hyper  node  (e.g.  it  includes  only  levels  3  to  5  for  a 
source  hyper  node  level  of  3). 

Concerning  the  derivation  of  the  clearance  level  and 
the  categoiy  set  of  a  given  user  role,  we  always  initialize 
the  level  to  be  one  (lowest  level)  and  the  category  to  be 
the  empty  set.  Then,  in  the  hierarchy  we  find  the  first 
entry  (occurrence)  of  the  role  and  we  move  towards  the 
top  of  the  hierarchy  by  following  its  connection  to  its 
ancestor  node.  In  case  it  is  a  branch,  we  increment  the 
clearance  level.  In  case  the  ancestor  node  is  a  regular 
node  we  assign  it  to  the  user  role  category.  When  the 
connection  is  ‘All  Users’  we  stop  moving  and  we  add  the 


last  category  found  to  the  category  set.  The  same  procedure 
is  repeated  for  every  subsequent  occurrence  of  the  user  role. 

The  derivation  of  the  security  (clearance)  level  of  a  user 
role  UR  is  described  in  the  following  algorithm  1. 

Algorithm  1:  Derivation  of  the  security  level. 
security  Jevel :  =  lowest Jevel 
until  connection(UR)  =  ‘All  Users’  do 
find  UR 

if  type  _of_cormection(\JR)  is  branch 
then  security  Jevel :  =  security  Jevel  +  1 
UR  :  =  connectionflJR) 

od 

The  following  algorithm  2  describes  the  derivation  of  the 
category  set  of  a  user  role  UR. 

/  orith  2  Derivation  of  the  category  set. 
find  UR 

category _set :  =  fcs(UR) 

function  fcs(A) 
fcs  :  =  {} 

if  type _of_no de ( A)  is  hyper  then  fcs  :  =  nodefA) 
if  connectionfA)  *  ‘All  Users’  then 
Anc :  =  connectionfA) 
f/nd  Anc 

if  fcs(Anc)  *  {}then  fcs  :  =  fcs(Anc) 
f/ndnex/  A 
while  A  exists  do 
fcs  :  =  fcs  u  fcs(A) 
f/ndnex/  A 
od 
fi 

fend 

The  use  of  the  URH  is  different  from  the  use  of  a 
classical  RBAC  hierarchy.  In  the  second  layer  of  the 
eMEDAC  model  (figure  1),  the  URH  is  used  to  inherit 
permissions.  However,  in  the  third  layer  the  URH  is  used 
for  deriving  security  labels  consisting  of  clearance  levels 
and  category  sets.  As  a  result,  the  two  basic  principles  of  the 
MAC  model  (18]),  which  are  the  simple-property  (or  read- 
up  protection)  and  the  ^-property  (or  write-down 
protection),  are  satisfied  in  a  subsequent  step  by  the  secure 
DBMS  implementing  the  following  dominance  relationship. 
A  security  label  Sj  =  (Lj ,  C2)  dominates  a  security  label  S2~ 
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(L: ,  C2)  if  and  only  if  L\  >  L:  and  C,  2  C:.  where  L  is  the 
security  level  and  C  is  the  category  set.  ([2]). 

In  order  to  demonstrate  the  above  concepts  we 
describe  below  a  representative  subset  of  our  pilot 
implementation.  The  general  model  of  a  HIS  architecture 
that  has  been  defined  by  the  ISHTAR  group  ([!]).  has 
been  used  as  the  basis  of  the  implementation  since  it 
corresponds  to  the  structure  of  the  AHEPA  General 
Hospital  that  is  used  as  our  test-bed  side.  The  four  main 
categories  of  activities  defined  in  this  model  have  been 
used  also  as  the  user  role  and  data  set  categories  :  ward, 
medical,  administration  and  logistics. 

In  our  implementation,  the  following  user  roles  have 
been  identified  ([12],  [13]). 


Doctor 

Id  .  . 

Nurse 

N _ 

Personal  doctor _ 

DP 

Head  Nurse 

NH 

On  dutv  doctor 

bo . 

On  dutv  nurse 

NO _ 

Head  doctor 

bH 

Trainins  nurse 

NT . 

Medical 

M 

Ward 

w 

Administration 

A _ 

Logistics 

L _ 

T able  .  User  roles  defined. 


Using  the  specialization  and  generalization  concepts 
the  URH  shown  in  figure  3  has  been  constructed. 

This  User  Role  Hierarchy  example  can  be 
implemented  using  the  data  structure  that  is  shown  in  the 
following  table  2. 


Type 
of  Node 

Node 

Type 

of  Connection 

Connection 

iSSSKS 

A 

link 

All  Users 

L 

link 

All  Users 

hvper 

W 

branch 

All  Users 

hyper 

M 

branch 

All  Users 

hyper 

N 

link 

W 

hyper 

NT 

link 

N 

hyper 

NO 

branch 

N 

hyper 

NH 

branch 

01 

dummy 

01 

branch 

N 

hyper 

D 

branch 

02 

dummy 

02 

branch 

M 

hyper 

DO 

branch 

D 

hyper 

[DP 

branch 

D 

hyper 

tDH 

branch 

D 

T able  2.  The  data  structure  used  for  the  URH  example. 


To  derive  the  security  label  (consisting  of  a  clearance 
level  and  a  set  of  categories)  of  the  user  role  NH  we 
initialize  the  level  to  be  one.  We  first  find  in  the  data 
structure  the  entry  of  node  NH.  Then  we  follow  its 
connection  that  is  a  branch  to  the  dummy  node  01  and  the 
level  is  incremented  by  one.  Again,  following  the  branch  of 
dummy  node  01  to  the  user  role  N,  the  level  is  incremented 
by  one.  Then  we  follow  the  link  of  N  to  W.  Because  the 
connection  of  W  is  ‘All  Users’  we  stop  moving,  the  node  W 
is  included  in  the  category  set  and  the  level  is  incremented 
by  one  having  now  the  final  value  four. 

3.5.  The  Data  Set  Hierarchy 

The  sensitivity  of  data  sets  is  expressed  in  a  similar  Data 
Set  Hierarchy  (DSH).  The  same  as  above  procedures  are 
applied,  except  that  data  sets  placed  on  the  top  of  the  DSH 
are  of  highest  level  (e.g.  5).  Each  sub-hierarchy  that  is 
generated  for  analyzing  further  the  inner  structure  of  a  data 
set  has  a  predefined  number  of  levels  and  cannot  include 
levels  higher  than  the  level  of  the  source  data  set  (e.g.  it 
includes  only  levels  1  to  3  for  a  data  set  level  of  3).  Cover 
stories  could  be  implemented  by  using  the  concept  of 
private  roles  ([18],  but  for  data. 


|  A  | - »All  Uscrs|<^ - \  L  | 

Level  1 

I~m~1  - PH< — 

— rwn 

1 - 1  Level  2 

(02)  foO  1  NO  I 

Level  3 

Level  4 

Level  5 

Figure  3.  The  User  Role  Hierarchy  (URH)  example. 

Concerning  the  derivation  of  the  sensitivity  level  and  the 
category  set  of  a  given  data  set,  we  always  initialize  the 
level  to  be  five  (highest  level)  and  the  category  to  be  the 
empty  set.  Then,  in  the  hierarchy  we  find  the  first  entry 
(occurrence)  of  the  data  set  and  we  move  towards  the  top  of 
the  hierarchy  by  following  its  connection  to  its  ancestor 
node.  In  case  it  is  a  branch,  we  decrement  by  one  the 
sensitivity  level.  In  case  the  ancestor  node  is  a  regular  node 
we  assign  it  to  the  data  set  category.  When  the  connection  is 
‘All  Data’  we  stop  moving  and  we  add  the  last  category 
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found  to  the  category  set.  The  same  procedure  is  repeated 
for  every  subsequent  occurrence  of  the  data  set. 

The  derivation  of  the  security  (sensitivity)  level  of  a 
data  set  DS  is  described  in  the  following  algorithm  3. 

Igorith  3  Derivation  of  the  security  level  in  DSH. 

security  Jevel :  =  highest  Jevel 

until  connection(DS)  =  ‘All  Data'  do 
find  DS 

if  type_of_connection(DS)  is  branch 
then  security  Jevel :  =  security Jevel  -  1 
DS  :  =  connection(DS) 

od 

The  algorithm  for  the  derivation  of  the  category  set  of 
a  data  set  DS  is  identical  to  the  algorithm  2  (defined  for 
user  roles). 

The  data  sets  are  allocated  at  each  node  depending  on 
the  need  to  know  principle  of  user  roles  and  the  specific 
security  constraints  that  are  implemented  by  the  secure 
design  methodology.  The  following  data  sets  have  been 
identified  for  the  pilot  implementation  ([12],  [13]). 


Administration 

A 

Physiotherapy 

HIP 

Patient  Identification 

I 

Pharmaceutical 

HIP 

Patient  Demographic  Data 

IN 

Radio  Treatment 

HTR 

Patient  Social  Data 

IS 

Exam  Orders  &  Results 

HE 

Insurance  Data 

n 

Clinical 

HEC 

Patient  Hospitalization 

H 

Laboratory 

HEL 

Medical  Decisions 

HD 

X-ray 

HEX 

Diagnoses 

HD 

Logistics 

L 

Diagnoses  (like  HIV) 

HD 

Cost-accounting 

LC 

Expectations 

HDE 

Administrative  data 

LA 

Therapeutic  Treatments 

HT 

Medical 

M 

T able  3.  Data  sets  defined. 


Using  the  above  data  sets  the  DSH  shown  in  figure  4 
has  been  identified  for  the  pilot  implementation. 

4.  Extensions  for  Distributed  Medical 
Databases 

Until  now,  the  discussion  addressed  mainly  the  needs 
of  centralized  database  systems.  However,  the  presented 
eMEDAC  security  policy  does  not  take  under 
consideration  any  additional  requirements  for  distributed 
database  systems  where  centralized  administration  of 


Figure  4.  The  Data  Set  Hierarchy  (DSH)  example. 

access  rights  is  a  very'  difficult  task.  In  such  a  case,  access 
control  systems  might  allow  administrative  authority  for  a 
subset  of  objects  to  be  delegated  by  the  global  security 
administrator  to  other  local  security  administrators.  For 
example,  authority  to  administer  objects  in  a  particular 
region  could  be  granted  to  the  regional  security 
administrator.  Control  over  the  regional  administrators 
could  be  also  centrally  administered,  but  they  could  have 
considerable  autonomy  within  their  regions.  The 
construction  of  a  local  HNH  (sub-hierarchies  for  local  user 
roles  and  data  sets)  could  be  accomplished  by  the  regional 
administrator  without  having  the  possibility  to  assign 
security  levels  higher  than  the  corresponding  global  user 
roles  and  data  sets  that  have  already  defined  by  the  global 
security  administrator.  This  process  of  delegation  could  be 
repeated  within  each  region  to  set  up  sub-regions  and  so  on 
([15]). 

However,  because  of  the  specific  needs  of  the  distributed 
systems  design  and  operation,  the  introduction  of  new 
proposals  or  the  extension  of  the  already  existing  ones  in 
eMEDAC  is  required.  In  our  opinion,  the  main  issue  is  the 
location  of  users  and  data  sets.  We  have  already  studied  the 
allocation  of  data  sets  in  the  context  of  a  secure  distributed 
database  design  methodology  ([8]).  However,  we  believe 
that  it  is  worth  to  study  the  impact  of  different  user 
locations  in  the  determining  process  of  access  control  for  at 
least  two  things.  First,  knowing  the  location  (site  or 
administrative  domain)  from  where  the  user  is  accessing 
remotely  the  database  system,  and  having  previously 
defined  the  trustworthiness  of  this  location,  the  decision  of 
what  set  of  roles  he  can  activate  depends,  besides  his  task 
requirements,  on  the  trustworthiness  of  his  current  location. 
Second,  knowing  the  location  (administrative  domain) 
wherein  the  user  is  acting,  the  decision  of  what  kind  of 


access  is  allowed  to  him  depends  not  only  on  his  current 
set  of  roles  but  also  on  its  particular  user  location. 

In  such  a  context,  we  consider  the  use  of  global  and 
local  access  control  mechanisms  in  distributed  medical 
database  systems.  As  has  been  proposed  in  [20],  global 
roles  could  be  authorized  with  global  permissions  to 
access  an  intranet's  resources  on  the  basis  of  different 
local  roles  in  different  servers  (sites).  However,  this 
assumption  introduces  lack  of  flexibility  (e.g.  the 
granularity  used  when  defining  the  permission  set)  and 
alike  behavior  of  the  access  control  system  on  local  and 
remote  access  requests.  We  prefer  to  define  separately 
each  one  subject  (global  or  local  user  role)  and  its 
permission  set  to  access  remotely  any  defined  object  of 
the  system  from  any  defined  location.  Our  perspective  is 
to  reduce  authorized  privileges  of  a  given  user  role  while 
its  location  is  going  farther  on  either  on  organizational  or 
security  level. 

As  with  user  roles  and  data  sets,  a  user  location 
hierarchy  is  resulting.  The  User  Location  Hierarchy 
(ULH)  is  a  means  for  representing  the  organizational 
structure  of  the  healthcare  establishments  involved  in  the 
application.  Furthermore,  in  a  ULH  can  be  included 
national  or  international  administrative  domains,  as  well 
as  a  number  or  all  the  possible  workstations  from  where  a 
given  user  can  log  in  the  distributed  medical  database 
system. 

As  a  result  of  this  the  total  amount  of  specifications  for 
defining  all  the  needed  data  can  easily  become  huge  and 
very  difficult  to  manage.  This  huge  amount  of  data  can  be 
reduced  however  dramatically  by  exploiting  the 
inheritance  in  the  already  presented  three  types  of 
hierarchies. 

In  each  administrative  domain  the  following  actions 
should  be  accomplished  for  the  definition  of  those 
hierarchies: 

•  Inherit  catalogues  and  hierarchies  of  user  roles,  data 
sets  and  user  locations  from  the  upper  (global) 
administration  domain, 

•  Refine  each  hierarchy  to  meet  the  special  local  needs 
of  the  specific  administrative  domain. 

However,  to  avoid  the  possibility  that  local  security 
administrators  could  decide  about  the  authorization  of 
subjects  of  their  administrative  domain  on  objects  that 
belong  to  other  domains,  it  is  obvious  that  there  must  be  a 
limit  in  the  penetration  that  other  administrators  can  do  in 
the  access  control  policy  of  each  administrative  domain 
([3]).  This  can  be  accomplished  by  eliminating  the  user 


role  permissions  set  on  the  basis  of  the  assigned  set  of  user 
locations.  To  achieve  this  a  third  dimension,  concerning  the 
user  location,  could  be  added  to  the  classical  access  matrix. 

In  our  oncoming  DIMED  AC  policy,  which  is  an 
extension  of  the  eMEDAC  security  policy  for  distributed 
database  systems,  we  have  attempted  to  cover  in  a 
satisfactory’  way  those  needs.  However,  this  is  beyond  the 
scope  of  this  paper. 

5.  Conclusion  and  Future  Work 

The  eMEDAC  security  policy  uses  RBAC  components 
to  provide  an  enhanced  redefinition  of  a  number  of 
mechanisms  of  the  already  known  MED  AC  security  policy. 
The  main  innovation  of  this  paper  when  compared  with  our 
previous  MEDAC  papers  is  related  to  the  use  of  RBAC 
mechanisms  in  all  the  three  layers  of  the  original  MEDAC 
security  policy. 

As  explained  in  the  paper,  the  use  of  RBAC  mechanisms 
in  the  third  layer  raises  several" problems  that  we  addressed. 
For  example,  the  construction  of  totally  ordered  security 
levels  and  the  definition  of  different  number  of  security  and 
hierarchy  (depth)  levels.  As  a  basic  solution  to  the  problems 
raised  we  proposed  the  Hyper  Node  Hierarchies  (URH  and 
DSH  hierarchies  of  any  depth,  derived  security  levels  and 
categories,  access  control  data  stored  separately  from  the 
application  data  holders,  etc.)  as  a  unique  mechanism  for 
inheriting  permissions  (discretional  control)  and  deriving 
security  labels  (mandatory  control).  The  proposed  concept 
of  the  HNH  mechanism  provides  a  flexible  number  of 
refinement  levels  that  is  not  strictly  equal  to  the  number  of 
mandatory  security  levels. 

Because  MAC,  DAC  and  RBAC  are  supported  in 
eMEDAC  at  the  same  time,  access  control  becomes  more 
efficient  and  hence  particularly  suited  to  security  critical 
environments,  like  the  health  care  ones,  where  all  three 
aspects  of  security  are  important. 

Administration  also  becomes  easier  because  the 
eMEDAC  policy,  besides  the  utilization  of  RBAC 
administration  advantages,  provides  the  ability  of  mixed 
centralized  and  decentralized  administration  control.  The 
Data  Set  Hierarchies  are  centrally  defined  and  stored 
separately  from  the  data  holders.  In  a  distributed  system 
both  URH  and  DSH  can  be  centrally  defined  and  replicated 
to  each  site.  The  local  administrators  can  add  more 
refinement  levels  for  satisfying  their  local  needs.  However, 
the  HNH  concept  specifies  (in  a  mandatory  way)  a  certain 
number  of  security  levels  that  cannot  be  overridden. 
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A  possible  disadvantage  is  a  non-significant,  to  our 
opinion,  loss  in  performance  (or  higher  computational 
workload)  which  stems  from  the  need  for  deriving  instead 
of  using  already  stored  security  labels.  However,  there  is 
expected  to  be  a  significant  saving  of  storage  space 
because,  instead  of  storing  security  labels  for  every  object 
(depending  on  the  selected  granularity,  e.g.  for  field 
granularity  the  storage  cost  becomes  considerable  high), 
only  the  necessary  nodes  of  HNH  are  stored. 

In  our  future  work  we  are  going  to  investigate  and 
compare  the  computational  and  storage  cost  of 
performing  access  control  by  deriving  security  labels 
instead  of  using  stored  ones.  We  also  are  working  to  study 
the  extensions  of  the  eMEDAC  that  are  necessary  in 
distributed  database  systems.  Furthermore,  the  case  of 
distributed  systems  with  mobile  parts  is  expected  to 
introduce  a  number  of  new  factors  affecting  the  overall 
access  control  system. 
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Abstract 

In  the  age  of  information  technology,  organizations  of  all 
types  are  seeking  to  effectively  utilize  and  disseminate 
information,  by  designing  and  developing  dependable  and 
secure  distributed  computing  environments  that  allow 
existing  and  future  systems  to  inter-operate.  While  many 
existing  access  control  approaches  (mandatory, 
discretionary,  and  role-based)  can  be  leveraged  for  the 
support  of  security  in  distributed  and  web-based  settings, 
their  assumptions  of  a  centralized  computing  model  may  be 
insufficient  in  a  distributed  setting.  In  recent  years,  agent 
computing  has  emerged  as  a  new  computing  paradigm, 
particularly  suited  to  distributed  and  web-based 
applications.  This  paper  explores  software  agents,  focusing 
on  their  ability  to  support  role-based  security  in  a  dynamic, 
object-based  setting  which  is  suitable  for  distributed  and 
web-based  applications.  The  agent  approaches  differ  in 
their  utilization  of  agents  (stationary  and  mobile)  and  the 
granularity  level  of  the  involved  classes/objects.  We  also 
report  on  our  prototyping  efforts  using  aglets,  a  Java-based 
mobile  agent  model  from  IBM. 

1.  Introduction 

Today's  and  tomorrow’s  distributed  and  web-based 
applications  will  be  comprised  of  existing  legacy, 
commercial-off-the-shelf  (COTS),  and  database 
applications  that  interact  with  new  clients,  servers, 
and  web-information  repositories,  as  organizations 
strive  to  allow  information  to  be  utilized  in  new  and 


innovative  ways.  The  fundamental  challenge  facing 
organizations,  software  architects,  system  designers, 
and  application  builders  (i.e.,  stakeholders)  involves 
the  ability  to  leverage  computing  and  networking 
resources,  and  data  and  information  in  existing 
applications,  to  construct  new  dependable  and  secure 
distributed  and  web-based  applications.  Our  focus  is 
on  the  secure  nature  of  distributed  and  web-based 
applications,  particularly  in  venues  which  promote 
electronic  banking,  commerce,  information 
dissemination  (push  and  pull),  and  so  on.  Distributed 
and  web-based  applications  will  require  researchers 
and  practitioners  to  design  security  solutions  that 
expand  and  transcend  available  alternatives. 
Traditional  alternatives  such  as  mandatory  access 
control  (MAC)  [Keef88,  Land84],  discretionary 
access  control  (DAC)  [Loch88,  Sand96],  and  role- 
based  security  (RBS)  [Demu97]  may  all  be  useful  to 
some  degree  as  stakeholders  and  security  engineers 
work  towards  the  establishment  of  a  cohesive  security 
policy.  Agent  computing,  which  first  emerged  just 
five  years  ago  [Gene94],  has  great  potential  for 
supporting  the  design/development  of  secure 
distributed  and  web-based  applications. 

Agents  act  on  the  behalf  of  individuals  (users), 
in  individual  or  collaborative  fashion,  to  assist  in  a 
particular  task,  hopefully  making  it  easier  for  users  to 
accomplish  what  they  intended.  Software  agents,  as 
computing  objects  have  a  specific  function  or 
responsibility  to  perform,  and  can  be  defined  in 


*  The  work  in  this  paper  has  been  partially  supported  by  a  contract  from  the  Mitre  Corp.  (Eatontown,  NJ)  and  a  research 
grant  by  AFOSR. 
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formal  terms  to  have  a  state  and  a  behavior  within  the 
runtime  environment.  Software  agents  have  four 
mandatory  properties  [Lang98]:  ability  to  sense  and 
react  to  changes  in  the  environment;  autonomous 
control  over  its  own  state  and  behavior;  proactive  to 
achieve  specific  goals  (typically  of  the  user);  and, 
constantly  executing  within  the  runtime  environment. 
Stationary  agents  are  restricted  to  a  single  computing 
node  in  accomplishing  their  tasks.  Mobile  agents  can 
migrate  to  a  new  location  in  order  to  execute  their 
required  responsibilities.  All  agents  are  like  other 
objects  in  that  they  can  be  created  and  destroyed. 
However,  agents  cannot  interact  by  invoking  each 
others  methods;  rather,  they  communicate  via 
message  passing. 

The  autonomous  and  mobile  nature  of  agents 
make  them  attractive  for  security  purposes.  For 
example,  one  scenario  could  have  agents  dynamically 
created  from  a  client  application  to  carry  out  the 
secure  access  to  objects  across  a  network.  In  such  a 
scenario,  the  agent  may  go  forth  and  visit  multiple 
nodes  to  collect/update  relevant  objects. 
Alternatively,  multiple  mobile  agents  may  be 
simultaneously  dispatched,  each  processing  a  single 
request,  to  achieve  parallel  processing  in  a  distributed 
setting.  Security  can  be  included  as  part  of  the  agent 
functionality,  providing  a  specificity  of  the  role  of  the 
client  that  dispatched  the  agent.  Note  also  that 
mobile  agents  are  a  significant  security  concern  from 
an  execution  perspective,  due  to  their  potential  ability 
to  act  as  a  threat,  and  that  there  must  also  be 
protection  of  the  agent's  state  from  a  malicious  host. 
These  two  critical  issues  are  beyond  the  scope  of  this 
paper. 

Our  intent  in  this  paper  is  to  present  and  explore 
various  scenarios  for  agent  approaches  to  security 
within  a  role-based  context  for  distributed  and  web- 
based  applications.  We  view  this  as  a  crucial  and 
important  first  step  in  understanding  the  different 
ways  that  agent  computing  models  can  be  utilized  to 
support  role-based  security.  Moreover,  if  agent 
computing  continues  to  increase  in  popularity  and 
usage,  it  is  incumbent  upon  the  research  community 
to  provide  security  solutions.  While  the  technology  is 
dangerous  from  a  security  perspective,  it  is  critical 
that  we  offer  strong  and  proven  solutions  to  guarantee 
varying  levels  of  secure  access  in  a  distributed  setting 
that  utilizes  agents.  The  research  community  must 
react  to  rapidly  changing  and  newly  emerging 
technologies. 


The  work  presented  in  this  paper  is  a  progression 
of  our  own  efforts  [Demu97,  Demu98,  Smar99],  with 
the  justification  to  pursue  this  effort  influenced  by 
other  researchers  [Hale96,  Hale98,  Tari98].  In  our 
previous  work  [Demu98],  we  explored  software 
architectures  alternatives  that  utilized  a  client/server 
paradigm  to  explore  role-based  security.  While  there 
was  distribution  in  some  of  the  alternatives,  the 
emphasis  was  on  relatively  static  architectures,  which 
is  inadequate  for  true  dynamic,  distributed  and  web- 
based  applications.  There  have  been  efforts  to 
investigate  security  for  distributed  objects  [Hale96], 
which  has  recently  been  extended  to  provide  a  secure 
distributed  object  and  language  programming 
framework  that  is  suitable  for  internet-based 
applications  [Hale98].  Another  effort  has  utilized  the 
Distributed  Object  Kernel  (DOK)  project  as  the 
underlying  framework  upon  which  software  agents 
can  operate  for  the  design  and  implementation  of 
distributed  security  policies  [Tari98].  Our  most  recent 
effort  has  explored  the  capabilities  and  the  potential 
impact  of  Java  on  security  for  distributed  computing 
[Smar99],  which  we  used  as  a  starting  point  to 
explore  agent  approaches  to  role-based  security, 
which  is  the  main  emphasis  of  this  paper. 

The  goal  of  this  paper  is  to  explore  the  potential 
of  agent  computing  in  support  of  role-based  security 
in  a  dynamic,  object-based  setting.  For  security  in 
distributed  and  web-based  applications  to  succeed,  it 
is  important  to  leverage  existing  security  techniques 
in  conjunction  with  emerging  approaches  to  arrive  at 
a  solution  for  the  21st  century.  The  remainder  of  this 
paper  is  organized  into  three  sections.  In  Section  2, 
we  detail  and  compare  three  architectures  of  agent 
approaches  for  role-based  security  in  a  dynamic, 
object  setting.  In  Section  3,  we  explore  our 
experimental  prototyping  efforts  with  one  of  the 
architectures  presented  in  Section  2  to  clearly 
demonstrate  the  feasibility  of  agent-solutions.  In 
Section  4,  we  conclude  by  offering  insight  into 
ongoing  efforts  and  future  plans.  Finally,  note  that 
issues  related  to  the  definition  and  management  of  a 
security  policy,  which  is  defined  for  both  clients  and 
servers  in  a  distributed  setting,  in  not  addressed 
herein;  rather,  it  is  the  subject  of  future  work. 

2.  Agent  Approaches  to  Role-Based  Security 

The  purpose  of  this  section  is  to  present  a  series  of 
agent  approaches  that  can  be  utilized  to  facilitate  the 
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role-based  access  of  remote  objects  by  users  in 
distributed  and  web-based  applications.  Security  for 
such  applications  must  occur  in  an  environment  that 
may  consist  of  legacy.  COTS,  database,  and 
new/existing  server  applications,  with  clients 
interested  in  obtaining  access  to  the  remote  objects 
that  reside  in  these  various  applications.  One 
interesting  aspect  of  security  is  that  its  goals  are  often 
orthogonal  at  some  level  to  the  goals  of  distributed 
computing  and  web-based  computing.  Security  has 
the  goal  of  controlling  and  limiting  certain  types  of 
interactions  while  distributed  and  web-based 
computing  is  concerned  with  enabling  interoperation 
and  facilitating  access  to  information.  Stakeholders 
must  carefully  balance  the  sometimes  contradictory 
goals  of  security  and  distribution  requirements  when 
constructing  distributed  computing  applications. 
Many  organizations  are  actively  distributing  their 
computing  and  offering  new  ways  to  access  both  old 
and  new  information,  without  regard  to  potential 
security  breaches  or  the  inadvertent  dissemination  of 
sensitive  information. 

For  discussion  purposes  within  this  paper,  we  are 
assuming  a  client/server  computing  model  for 
distributed  and  web-based  applications.  Specifically, 
in  our  client/server  model,  a  client  application  is 
interested  in  sending  a  request  to  access/modify  a 
remote  object,  with  the  allowable  actions  on  the 
remote  object  dictated  by  the  role  of  the  user  (client). 
In  our  role-based  model  for  DAC  [Demu97],  a 
customizable  public  interface  is  promoted,  that 
appears  differently  at  different  times  for  specific 
users.  We  have  proposed  the  concept  of  a  potential 
public  interface  for  all  classes,  which  contains  those 
methods  that  are  most  likely  to  be  made  public  on  a 
role-by-role  basis.  The  methods  that  each  role  needs 
from  each  application  class  defines  the  security 
requirements  for  that  role.  The  basic  premise  is  that, 
for  each  role,  we  track  the  positive  permissions, 
namely,  can  a  user  role  invoke  a  particular  method  on 
an  object.  Collectively,  all  of  these  security 
requirements  form  a  foundational  part  of  the  security 
policy  for  an  application.  Our  assumption  in  this 
paper  is  that  the  client  will  play  a  role  and  make  a 
request  to  invoke  a  method  on  a  remote  object. 
Agents  will  be  dispatched  to  attempt  to  carry  out  that 
request,  with  a  success  or  failure  result.  The 
interested  reader  is  referred  to  our  efforts  at  UConn 
on  extensible  and  reusable  DAC  enforcement 
mechanisms  for  a  detailed  overview  of  our  role-based 
security  model  [Demu97].  This  expertise  has  been 
crucial  in  formulating  the  architecture  agent  variants 


presented  herein  and  in  prototyping  the  agent-based 
approaches  presented  in  Section  3. 

Thus,  the  scenario  is  that  a  client  application  is 
making  a  request  (i.e.,  a  method  invocation)  to 
access/modify  a  remote  object,  that  may  be  residing 
in  a  legacy,  COTS,  database,  or  server  application.  In 
such  a  scenario,  we  want  the  request  to  be  processed 
according  to  the  defined  security  policy  for  the  client 
application  in  a  dynamic  setting.  In  our  role-based 
security  model,  this  requires  that,  for  each  user  role, 
we  maintain  a  list  of  the  permissions  (which  methods 
can  be  invoked)  on  all  classes  in  an  application. 
Agents  are  attractive  in  such  a  setting,  since  they 
allow  autonomous  and  mobile  actions  to  occur  on 
behalf  of  a  client.  In  our  case,  these  actions  will 
authenticate  the  identity  and  role  of  the  client 
application,  will  bundle  the  client  request  (method 
invocation)  and  user  role  within  a  message,  and  then 
dispatch  agents  that  can  move  across  computing 
nodes  for  the  secure  access  of  remote  objects. 

In  this  section,  we  present  three  agent 
approaches  that  support  role-based  access  for 
distributed  and  web-based  applications: 

•  A  baseline  agent  approach  that  represents  a  core 
set  of  system  components  and  agents  (both 
stationary  and  mobile)  to  facilitate  the  remote 
access  to  an  object. 

•  A  hierarchical  agent  approach  that  expands  on 
the  baseline  approach  to  spawn  a  series  of 
multiple  agents  for  simultaneously  accessing 
remote  objects  in  multiple  locations. 

•  An  object-security  manager  agent  approach  that 
extends  the  hierarchical  approach  to  include  the 
access  of  multiple  remote  objects  in  the  same 
location. 

The  remainder  of  this  section  reviews  each  approach 
in  detail,  followed  by  a  summary  that  compares  the 
three  approaches.  Finally,  note  that  while  we  have 
employed  a  role-based  paradigm  for  security,  there  is 
nothing  in  the  ideas  presented  in  this  section  that  will 
restrict  our  solution. 

2.1  Baseline  Agent  Approach 

The  architecture  for  the  baseline  agent  approach  is 
presented  in  Figure  1,  and  is  partitioned  into  a  client 
computing  node  (upper  half  of  figure)  and  a  server 
computing  node  (lower  half  of  figure).  The 
components  and  agents  are  as  follows: 
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Figure  1:  Architecture  for  Baseline  Agent  Approach. 


•  Client  Application  (CA):  This  component  is  the 
graphical  interface  or  software  tool  that  is  utilized 
by  the  user  to  perform  a  specific  set  of  tasks.  The 
user  is  restricted  to  playing  a  single  role  at  any 
time,  and  both  the  role  and  request  are  passed 
from  CA  to  the  user  agent  (UA)  for  processing. 
Users  can  access/modify  only  a  single  remote 
object  at  a  time  via  CA.  If  multiple  remote 
objects  are  to  be  accessed/modified,  there  must  be 
functionality  within  CA  that  allows  such  a 
request  to  be  separated  into  a  series  of  individual 
object  accesses.  Agent  approaches  in  Sections 
2.2  and  2.3  will  consider  requests  that  involve 
access  to  multiple  remote  objects. 

•  User  Agent  (UA):  This  is  a  stationary  agent  that 
is  created  upon  the  request  of  the  client  to 
represent  the  user.  UA  receives  a  request  from 
the  client,  transforms  the  request  to  the  proper 
format,  creates  the  information  retrieval  agent 
(IRA),  forwards  the  request  to  IRA,  waits  for  the 
processing  of  the  request,  collects  the  results  of 
the  request  from  IRA,  and  transforms  and  then 
returns  the  results  to  CA. 

•  Information  Retrieval  Agent  (IRA):  This  is  a 
mobile  agent  that  is  created  by  UA  for  processing 
the  request  of  CA.  In  this  baseline  approach,  the 


IRA  is  limited  to  interacting  with  the  UA  on  the 
client  side  and  object  security  agent  (OSA)  on  the 
server  side.  IRA  is  created  and  dispatched  by  UA 
to  access  a  single  remote  object  on  the  server 
side,  if  permitted  by  the  role  of  the  user. 

•  Object  Security  Agent  (OSA):  This  can  be  a 
stationary  agent  (collection  of  security  objects)  or 
a  mobile  agent.  In  either  case,  OSA  enforces  the 
security  policy  of  the  object  that  is  based  on  the 
permissible  actions  of  each  role.  Each  OSA  is 
effectively  providing  control  to  a  remote  object. 
The  remote  object  may  be  a  single  object  or  a 
collection  of  objects  (aggregation).  In  the  latter 
case,  this  is  essentially  a  database,  and  OSA  is 
serving  as  a  layer  or  wrapper  to  interact  with  the 
collection  of  objects. 

•  Object:  The  remote  object  that  is  available  to 
provide  services  to  CAs.  A  remote  object  may  be 
a  single  instance  or  a  collection  of  related 
instances  (e.g.,  a  person  database  is  a  single 
remote  object). 

While  the  above  represents  an  overview  of  the 
capabilities  of  each  component  in  Figure  1,  it  is 
important  that  we  examine  UA,  IRA,  and  OSA  in 
greater  detail,  to  fully  understand  the  subtleties 
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involved  in  their  interactions  and  lifetimes.  In  some 
situations,  there  are  alternative  scenarios  that  are 
plausible  based  on  the  assumptions  and  operating 
environment.  These  alternatives  will  be  mentioned 
and  critiqued  throughout  our  discussion  on  the  agent 
approaches. 

The  baseline  agent  approach  represents  a  core 
strategy  with  significant  and  limiting  assumptions: 

1.  The  client  formulates  simple  requests  that  involve 
the  access  of  a  remote  object  by  a  single  method 
call.  Each  request  may  invoke  a  single  method  on 
a  single  remote  object. 

2.  UA  is  able  to  process  multiple  requests  by  the 
client  in  a  synchronous  fashion.  Thus,  there  may 
be  multiple  active  IRAs  processing  requests 
simultaneously. 

3.  Authentication  of  the  user  must  occur  prior  to  the 
spawning  of  an  IRA  to  respond  to  a  request.  We 
are  assuming  that  this  will  take  place  in  either  CA 
or  by  UA. 

4.  While  a  remote  object  refers  to  a  single  instance, 
that  instance  may  be  a  person  record  (e.g.,  name, 
address,  etc.)  or  a  collection  instance  (e.g.,  the 
collection  of  all  person  records).  In  the  latter 
case,  the  single  remote  object  contains  multiple 
instances  that  are  controlled  and  managed  like  a 
database  within  the  collection. 

The  idea  for  the  baseline  agent  approach  is  to  limit 
functionality  by  mandating  that  complex  requests  that 
require  synchronization  (results  of  one  request  drive 
submittal  of  successive  requests)  are  handled  by  the 
client.  While  it  may  be  argued  that  this  is 
unrealistically  limiting,  our  intent  is  to  provide  a 
simple  model  for  those  situations  where  the  majority 
of  the  processing  already  exists  in  CA,  which  may 
occur  when  the  client  is  a  legacy/COTS  application. 

2.1.1  User  Agent 

The  user  agent  (UA)  is  a  stationary  agent  that  is 
utilized  by  the  client  application  when  the  user 
requests  that  an  action  be  initiated  on  his/her  behalf. 
The  user,  via  CA,  can  only  play  a  single  role  at  any 
given  time.  UA  is  the  interaction  medium  between 
CA  and  the  mobile  IRA.  The  UA  receives  a  coded 
request  (i.e.,  user  role  and  method  to  invoke)  from 
CA,  forwards  the  request  to  IRA,  and  waits  for  the 
response  from  IRA.  For  the  baseline  approach  of 
Figure  1,  UA  receives  a  single  request  to  access  one 


remote  object.  There  are  two  different  UA  allocations 
strategies: 

•  User-Based  Allocation:  In  this  situation,  a  UA  is 
allocated  and  dedicated  to  an  individual  user 
when  the  client  application  commences  and  the 
user  logs  on  to  a  session.  Essentially,  a  dedicated 
UA  can  enforce  the  single  role  that  the  client 
plays  and  manage  all  of  the  synchronous  requests 
that  will  be  submitted  to  dedicated  IRAs  (one 
IRA  per  request).  If  multiple  CAs  are  executing 
on  the  same  client  node,  then  multiple  UAs  will 
compete  for  computing  resources. 

•  Role-Based  Allocation:  In  a  multi-user 
environment,  where  multiple  users  are  active,  it 
makes  sense  to  explore  an  allocation  strategy  that 
is  based  on  role.  In  this  situation,  dedicated  UAs 
are  allocated  for  each  role,  and  shared  by  the 
many  users  (CAs)  that  are  playing  the  same  role. 
UAs  are  allocated  whenever  there  is  a  request  for 
a  user  (CA)  to  play  a  role,  and  that  role  is  not 
supported  by  an  active  UA.  When  a  UA  is  no 
longer  being  utilized  by  any  active  CA,  then  it 
can  be  de-allocated. 

In  both  UA  allocation  strategies,  multiple  IRAs  may 
be  active  and  managed  (i.e.,  created,  dispatched,  and 
destroyed)  by  the  single  UA;  the  difference  is  that  in 
user-based  allocation  there  is  one  client/UA,  while  in 
role-based  allocation  there  is  one  UA/role.  The 
allocation  above  is  based  on  the  assumption  that  a 
user  (CA)  can  only  play  one  role  at  any  given  time.  If 
a  user  can  play  multiple  roles  simultaneously,  user- 
based  allocation  is  still  feasible,  since  each  UA  will 
embody  the  security  policy  for  the  multiple  roles 
being  played.  However,  role-based  allocation 
becomes  problematic.  Since  the  security  privileges 
for  a  user  are  spread  across  multiple  UAs,  the  UAs 
would  be  required  to  communicate  to  synchronize 
their  activities.  Thus,  the  lifetime  of  UA  can  vary 
based  upon  different  scenarios  of  CA  behavior  within 
a  shared  client  computing  node. 

2.1.2  Information  Retrieval  Agent 

The  information  retrieval  agent  (IRA)  is  a  mobile 
agent  that  is  created  by  UA  on  the  client  side  to 
process  the  request  of  the  user  (from  CA).  The 
purpose  of  the  IRA  is  two  fold:  (1)  separation  of 
concerns  to  allow  the  IRA  to  be  mobile  and  interact 
with  remote  objects  and  (2)  to  exploit  parallel  and 
distributed  processing  by  having  multiple  IRAs  active 
to  process  requests  (invoke  methods)  for  a  given  CA 
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and  managed  by  a  UA.  In  the  baseline  agent 
approach,  the  request  to  be  processed  by  IRA  will  be 
limited  to  a  single  remote  object.  As  a  mobile  agent, 
ERA  is  able  to  move  to  the  host  computer  (server  side) 
where  the  object  resides  that  is  needed  to  satisfy  the 
user's  request.  IRA  carries  the  user  request  (which 
method  to  invoke)  and  the  current  role,  which  are 
both  needed  to  interact  with  the  object-security  agent 
(OSA)  to  process  the  request.  That  is,  the  OSA  will 
validate  whether  the  IRA  is  permitted  to  ask  for  the 
method  to  be  invoked  on  the  remote  object  based  on 
the  user  role  being  represented  by  the  ERA.  In  the 
baseline  agent  approach,  IRA  moves  to  the 
destination  and  exchanges  information  with  OSA. 
Once  the  IRA  has  received  a  response  (success  or 
denied  access)  from  OSA,  it  takes  that  response, 
ceases  its  action,  and  moves  back  to  the  client  side  to 
return  the  result  to  UA,  which  will  then  forward  the 
response  to  CA.  As  in  Section  2.1.1,  there  are  two 
different  scenarios  for  the  lifetime  of  IRA  that  share  a 
common  basis,  IRA  is  allocated  by  UA  for  the  first 
request  of  a  remote  object  by  CA. 

1.  ERA  stays  alive  as  long  as  UA  is  active.  In  this 
case,  a  single  IRA  can  process  all  requests  by  a 
client  in  a  sequential  manner,  starting  a  new 
request  only  after  the  current  request  has  been 
completed.  This  scenario  reduces  the  overhead 
associated  with  creating  and  destroying  a  mobile 
agent. 

2.  ERA  is  de-allocated  when  it  finishes  processing  a 
request.  In  situations  were  access  to  remote 
objects  by  clients  is  infrequent,  this  scenario 
benefits  by  not  having  active,  idle  agents. 

The  first  scenario  will  not  support  multiple  active 
requests  being  spawned  by  UA  for  simultaneous 
processing  by  ERA.  The  second  scenario  supports 
such  a  situation,  since  multiple  independent  IRAs  can 
be  spawned  that  move  to  remote  locations  to  access 
objects.  This  will  require  UA  to  have  additional  logic 
to  be  able  to  process  a  queue  of  simultaneous  requests 
from  the  same  or  different  users. 

Finally,  note  that  in  the  baseline  agent  approach 
and  the  others  to  be  discussed  in  Section  2.2  and  2.3, 
we  are  making  the  assumption  that  an  IRA  processes 
one  request  to  invoke  one  method  on  a  single  remote 
object.  The  intent  of  this  assumption  is  to  allow  the 
IRA  to  be  lean  or  thin,  targeted  to  a  very  simple  and 
easy  to  carry  out  task.  This  assumption  is  in  line  with 
the  idea  that  the  baseline  agent  approach  only 
processes  simple  requests.  There  may  be  multiple 


IRAs  active  at  the  same  time  for  a  single  UA, 
working  on  individual  requests  that  will  each  invoke  a 
single  method  on  a  single  remote  object.  Having  a 
single  ERA  travel  to  multiple  locations  isn't 
appropriate  for  the  baseline  agent  approach,  but  may 
be  relevant  for  the  other  approaches,  as  we  will 
discuss  in  Sections  2.2  and  2.3. 

2.1.3  Object  Security  Agent 

The  object  security  agent  ( OSA )  can  be  conceptually 
regarded  as  the  firewall  that  separates  the  remote 
object  from  the  outside  world.  OSA  embodies  the 
security  policy  for  the  remote  object,  which  in  our 
case,  is  a  role-based  approach  that  dictates  which  role 
can  access  which  method  on  the  object  [Demu97, 
Demu98].  OSA  receives  a  request  to  access  a  remote 
object  via  the  mobile  ERA,  and  based  on  the 
privileges  of  the  role,  will  either  deny  or  respond  to 
the  request.  For  our  purposes,  OSA  must  validate  the 
privileges  carried  by  ERA  (user  role  and  method  to 
invoke)  against  the  applications  security  policy  for 
that  object/class.  OSA  is  a  gatekeeper  to  the  remote 
object,  but  is  important  to  again  stress  that  the  remote 
object  may  not  be  a  single  instance,  but  may  be  a 
collection  of  instances.  A  person  collection  is  a 
single  instance  of  the  collection  class  that  contains 
multiple  person  instances.  OSA  may  manage  a  single 
instance  (the  "Steve"  instance)  or  an  entire  collection 
(the  "PersonDB"  instance  which  contains  instances 
for  "Steve",  "T.C",  "Ying",  "Mitch",  etc.).  Thus,  a 
remote  object  of  an  object  oriented  application  is 
equivalent  to  a  database. 

The  OSA  component  can  be  designed  and 
implemented  as  either  a  set  of  security  objects  or  a 
mobile  agent.  If  OSA  is  a  set  of  security  objects,  it  is 
tightly  bound  to  the  class  (type)  of  the  remote  object, 
and  the  supported  security  policy  will  be  one  of  the 
object-oriented  role-based  techniques  we  have 
described  in  our  earlier  work  [Demu97].  Allocation 
of  OSA  in  this  situation  will  occur  when  the  remote 
object  is  instantiated.  If  the  OSA  is  an  agent,  it  must 
be  a  separate  entity  from  the  remote  object.  The 
security  policy  that  is  supported  in  this  situation  can 
occur  at  the  class  (type)  or  object  (instance)  levels.  In 
this  case,  there  are  a  number  of  strategies  for  OSA 
allocation: 

1.  When  the  number  of  remote  objects  on  a  given 
computing  node  is  “small”  (or  the  number  of 
objects  that  are  typically  accessed  is  small),  then 
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allocate  a  single  OSA  that  is  shared  by  all  of  the 
remote  objects  on  the  same  server. 

2.  When  the  number  of  remote  objects  is 
“moderate”  (or  the  number  of  objects  that  are 
typically  accessed  is  moderate),  then  allocate  an 
OSA  for  every  remote  object  (instance). 

3.  When  the  number  of  remote  objects  is  “large”, 
but  the  number  of  involved  classes  (types)  is 
small,  allocate  an  OSA  for  each  class  (type)  of 
remote  objects. 

In  either  of  these  strategies,  OSA  will  contain  an 
aggregation  of  the  security  policies,  i.e.,  methods  that 
can  be  invoked  by  all  roles  for  all  classes/objects. 
There  are  clear  tradeoffs  to  be  made  in  the 
aforementioned  three  strategies,  particularly  when 
one  considers  the  frequency  of  access  of  remote 
objects  by  IRAs.  For  example,  a  single,  shared  OSA 
per  server  will  quickly  be  overload  by  multiple  IRA 
requests.  Moreover,  as  activity  increases  and  the 
numbers  of  mobile  IRAs  increase,  regardless  of  the 
scenario,  it  is  likely  that  another  component  would  be 
needed  to  oversee  the  interactions  of  IRAs  with 
multiple  OSAs.  This  will  be  discussed  in  Section  2.3. 

2.2  Hierarchical  Agent  Approach 

The  baseline  agent  approach  was  limited  to  simple 
requests  that  can  be  submitted  synchronously  without 
coordination  of  results.  The  assumption  was  that  CA, 
likely  a  legacy  or  COTS  application,  would  handle 
the  processing  of  complex,  nested  requests.  In 
practice,  requests  by  clients  are  often  complex, 
requiring  multiple  methods  to  be  invoked  in  a 
particular  sequence,  similar  to  the  concept  of  a  nested 
transaction.  The  hierarchical  agent  approach  is 
appropriate  when  there  are  thin  clients  (e.g.,  a 
browser)  and  the  processing  of  complex  requests 
must  be  offloaded  to  either  UA  or  IRA. 

Figure  2  contains  a  representation  of  the 
architectural  components  for  the  hierarchical  agent 
based  approach  which  was  designed  to  handle 
complex  requests.  While  similar  to  Figure  1,  the 
major  difference  is  a  hierarchical  collection  of  mobile 
IRAs  that  are  able  to  handle  complex  requests 
submitted  by  the  client  via  UA.  A  minor  difference 
in  the  figure  has  the  Security  Policy  listed  as 
independent  from  OSA;  in  fact,  as  discussed  in 
Section  2.2.3,  it  can  be  incorporated  within  OSA.  In 
the  baseline  agent  approach,  the  strong  assumption 
was  made  that  a  user  submits  a  request  to  access  an 


individual  remote  object.  Any  complex,  ordered 
request  must  be  submitted  as  a  series  of  sequential 
single  requests,  with  UA  handling  the  submittal  of 
requests  and  collection  of  results.  In  the  hierarchical 
agent  approach,  the  logic  in  the  IRA  has  been 
enhanced  to  support  complex  requests  involving 
multiple  remote  objects  on  possibly  different 
computing  nodes. 

To  support  complex  requests,  there  are  three 
different  types  of  IRAs:  root-IRA,  intemal-IRA,  and 
leaf-lRA.  A  roof-ERA  interacts  with  UA  to  handle 
and  oversee  complex  requests  that  involve  multiple 
remote  objects.  The  root-IRA  is  spawned  by  UA,  and 
in  turn  can  spawn  other  IRAs  to  handle  complex 
requests.  If  the  complex  request  is  a  series  of 
requests  that  involve  access  to  individual  remote 
objects,  the  root-IRA  will  spawn  a  series  of  leaf- 
IRAs.  A  leaf-IRA  is  similar  in  concept  to  the  mobile 
IRA  discussed  in  Section  2.1.2,  and  is  intended  to 
process  the  request  for  access  to  a  remote  object  by 
moving  across  the  network  to  another  node.  A  leaf- 
IRA  interacts  with  OSA  to  answer  the  user  request, 
and  returns  its  result  to  the  root-IRA.  Figure  2 
depicts  a  situation  where  there  is  one  root-IRA  and 
two  leaf-IRAs.  Each  leaf-IRA  takes  the  request  to 
access  a  single  remote  object  and  moves  to  the 
appropriate  computing  node  to  interact  with  an  OSA 
according  to  the  scenario  described  in  Section  2.1. 
The  two  leaf-IRAs  in  Figure  2  could  move  to  the 
same  or  different  computing  nodes  to  accomplish 
their  respective  tasks.  Upon  their  return,  the  root-IRA 
collects  the  results  for  forwarding  to  UA  and 
eventually  the  user.  Note  that  in  the  case  where  a 
simple  request  for  a  single  remote  object  is  made,  the 
root-IRA  may  be  designed  in  such  a  way  as  to  process 
the  request,  or  the  root-IRA  may  spawn  a  single  leaf- 
IRA.  In  the  former,  root-IRA  would  be  a  mobile 
agent,  in  the  latter,  it  would  be  stationary. 

While  Figure  2  only  illustrates  two  levels  of 
IRAs,  in  fact,  there  can  be  multiple  levels,  based  on 
the  complexity  of  the  user  request.  If  the  root-IRA 
decomposes  the  user  request  into  multiple  complex 
sub-requests,  each  of  these  sub-requests  would  be 
dispatched  to  an  intemal-IRA  for  processing.  That  is, 
an  intemal-IRA  is  spawned  to  handle  complex  sub¬ 
requests.  An  intemal-IRA  will  in  turn  spawn  either 
intemal-IRA  or  leaf-IRA,  to  process,  respectively, 
complex  sub-requests  (multiple  remote  objects)  or 
simple  requests  (single  remote  object).  Recursive 
spawning  of  IRAs  will  continue  until  the  state  of  all 
leaf-IRAs  is  reached.  As  intemal-IRAs  and  leaf-IRAs 
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complete  their  actions,  their  responses  will  be 
collected  by  intemal-IRAs,  and  eventually  the  root- 
IRA.  In  the  aforementioned  situation,  the  root-IRA  is 
stationary;  intemal-IRAs  can  be  either  stationary  or 
mobile. 

From  an  allocation  perspective,  one  approach 
would  have  a  root-IRA  allocated  for  each  UA,  whose 
lifetime  is  under  the  control  of  UA.  Internal  and  leaf 
IRAs  would  be  created  by  the  root-IRA  as  needed  to 
process  user  requests.  Since  only  one  root-IRA  exists 
for  each  UA.  the  requests  from  the  clients  can  be 
handled  in  a  synchronized  fashion.  However,  unlike 
the  baseline  agent  approach,  CA  can  submit  complex 
requests  to  UA  which  are  then  passed  to  root-IRA  for 
processing.  The  internal  and  leaf  IRAs  that  are 
spawned  can  process  the  sub-requests  in  a  parallel 
fashion,  by  dispatching  mobile  agents  (leaf-IRAs)  to 
remote  object  locations. 

Again,  like  the  baseline  agent  approach,  we  have 
adopted  the  strategy  that  each  leaf-IRA  will  process  a 
single  user  request  (method  invocation)  on  a  single 
remote  object.  Clearly,  we  could  have  modeled  a 
different  strategy  where  the  single  IRA  can  visit 
multiple  locations  to  satisfy  a  complex  request  of  CA. 
However,  our  top-down  strategy  of  root-IRAs 
spawning  intemal-IRAs  spawning  leaf-IRAs,  is  more 
suited  to  having  each  leaf-IRA  visit  a  single  remote 
object,  and  then  require  the  intemal-IRAs  to  collect 
and  synthesize  results  in  a  bottom-up  manner, 
eventually  arriving  at  the  root-IRA.  A  different 
strategy  could  have  had  each  intemal-IRA  spawn  a 
single  leaf-IRA  that  would  have  a  list  of  multiple  user 
requests  requiring  access  to  potentially  multiple 
remote  objects.  The  single  leaf-IRA  could  visit 
multiple  servers  in  pursuit  of  all  relevant  remote 
objects.  The  tradeoffs  are  as  follows: 

1.  The  single  leaf-IRA  for  an  internal  IRA  may  slow 
down  processing,  since  the  intemal-IRA  may 
need  to  get  interim  results  from  the  single  leaf- 
IRA  before  the  same  leaf-IRA  is  dispatched  to 
other  nodes. 

2.  The  multiple  leaf-IRAs  may  slow  down 
processing  at  the  client  side  with  many  agents 
that  must  be  tracked  and  managed. 

There  should  be  no  impact  on  the  server  side  in  either 
situation,  since  the  number  of  visits  is  the  same;  who 
is  visiting  is  what  has  changed. 


2.3  OSA  Manager  Agent  Approach 

The  final  architecture,  the  object-security  manager 
agent  approach ,  is  presented  in  Figure  3,  and  expands 
the  hierarchical  agent  approach  by  the  addition  of  an 
OSA  Manager.  The  OSA  Manager  is  intended  to 
assist  in  OSA  allocation  strategies  as  discussed  in 
Section  2.1.3.  OSA  Manager  is  responsible  for 
arranging  and  overseeing  the  allocation  of  the  OSA. 
Recall  from  Section  2.1.3  that  we  can  allocate  OSA  in 
a  number  of  ways:  one  per  server  when  there  are 
“few”  remote  objects,  one  per  object  for  a  “moderate” 
number  of  objects,  or  one  per  class,  for  a  “few” 
classes  that  have  many  instances.  Rather  than  having 
one  of  these  alternatives  chosen  in  a  static  fashion  at 
start  up,  an  OSA  Manager  can  dynamically  pick  and 
choose  the  best  allocation  strategy  for  controlling 
access  to  remote  objects  during  execution,  in  reaction 
to  the  state  of  the  system,  i.e.,  number  of  IRAs  at 
client,  number  of  remote  objects  being  accessed,  etc. 
In  some  situations,  an  OSA  Manager  might  have  an 
OSA  for  multiple  objects  coexisting  with  other  OSAs 
that  are  dedicated  to  specific  classes.  The  OSA  agent 
approach  extends  the  hierarchical  approach  by  adding 
another  layer  of  management  at  the  server  side  to 
insure  that  the  collections  of  remote  objects  are  being 
managed  in  a  fashion  that  is  most  suited  to  the 
execution  environment  of  the  running  application. 

Processing  by  mobile  IRAs  must  now  be  altered 
to  communicate  with  OSA  Manager  to  obtain 
information  on  the  OSAs  to  be  contacted  for  remote 
object  access.  That  is,  upon  arriving  at  a  server,  an 
IRA  asks  OSA  Manager  where  to  find  a  specific 
remote  object.  OSA  Manager  returns  the  identity  of 
the  OSA  that  is  controlling  the  remote  object.  Once 
the  identity  has  been  received,  IRA  contacts  the 
correct  OSA  and  proceeds  to  process  the  user  request. 

The  biggest  advantage  to  an  OSA  Manager  is  to 
have  tight  and  dynamic  control  over  the  OSAs  that 
are  resident  on  a  server  for  processing  user  requests. 
Security  policies,  which  reflect  the  application 
environment  and  conditions,  are  ever-changing,  and 
the  OSA  Manager  approach  allows  us  to  easily  alter 
the  allocation  strategy  for  OSAs.  In  fact,  OSA 
Manager  can  maintain  historical  information  on  OSA 
access  by  IRAs,  which  can  be  utilized  to  terminate 
infrequently  used  OSAs,  or  change  from  instance- 
based  to  class-based  allocation.  In  the  object-security 
manager  agent  approach,  OSAs  don't  have  to  be 
statically  created  at  system  initialization. 
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Figure  2:  Architecture  for  Hierarchical  IRA  Approach. 


Figure  3:  Architecture  for  OSA  Manager  Approach. 
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2.4  Summarizing  Approaches:  Baseline  vs. 
Hierarchical  vs.  OSA  Manager 

The  three  approaches  presented  in  Sections  2.1,  2.2, 
and  2.3  represent  a  progression  based  on  a  number  of 
different  dimensions.  From  the  dimension  of  client 
functionality,  the  baseline  agent  approach  is 
particularly  well  suited  for  legacy/COTS  clients, 
where  individual  requests  (method  invocations)  can 
be  captured  and  sent  to  UA  for  processing.  Since  the 
functionality  within  the  client  in  this  situation  is 
typically  inaccessible  (no  source  code),  it  makes 
sense  to  decompose  the  problem  and  send  simple 
requests  to  UA  which  in  turn  create  and  dispatch 
IRAs  as  needed.  The  hierarchical  and  OSA  Manager 
will  work  in  this  situation,  but  are  better  suited  for 
thin  clients  (e.g.,  browsers),  where  significant 
application  functionality  is  then  offloaded  to  UA  and 
IRA.  From  the  dimension  of  UA  allocation,  all  three 
approaches  are  able  to  use  either  user-based  or  role- 
based  allocation  (see  Section  2.1.1  again).  The 
different  allocation  strategies  are  based  more  on 
client  activity  than  on  the  agent  behavior,  as  was 
discussed.  From  the  dimension  of  adaptability  of 
server  to  IRA  frequency  and  load,  the  OSA  Manager 
approach  is  superior.  OSA  Manager  is  intended  to 
adapt  the  allocation  of  OSAs  to  remote  objects  based 
on  the  access  patterns  of  the  agents,  ranging  from  one 
OSA/remote  object  to  one  OSA/class  to  one 
OSA/server.  In  the  baseline  and  hierarchical 
approach,  allocation  of  the  OSAs  would  be  fixed  at 
system  initialization.  Finally,  from  the  dimension  of 
complex  request  processing,  the  hierarchical  and 
OSA  Manager  approaches  are  equivalent  in  their 
ability  to  support  nested  transactions.  All  three 
approaches  are  controlling  access  to  remote  objects, 
which  may  range  from  small,  individual  instances 
(e.g.,  the  Person  "Steve")  to  collection  instances  (e.g., 
the  PersonDB  collection  of  Persons)  . 

3.  A  Java  Aglet  Implementation 

Stationary  and  mobile  software  agents  in  Java  are 
supported  by  a  number  of  different  agent  based 
systems,  including  Aglets  [Agle],  Odyssey  [Odys], 
Concordia  [Cone],  and  Voyager  [Voya].  For  the 
purposes  of  our  implementation  efforts,  we  have 
chosen  IBM’s  aglets,  which  was  named  by  combining 
the  terms  of  agent  and  applet.  Unlike  a  Java  applet, 
an  aglet  continues  execution  where  it  left  off  (upon 
reaching  a  new  location).  This  is  possible  because  an 
aglet  is  an  executable  object  (containing  both  code 


and  state  data)  that  is  able  to  move  from  computing 
node  to  computing  node  across  a  network.  Like 
applets,  aglet  actions  should  be  restricted  to  a  Java 
sandbox.  The  sandbox  model  supports  the  running  of 
untrusted  code  in  a  trusted  environment  so  that  if  a 
hostile  aglet  is  received,  that  aglet  cannot  damage  the 
local  machine.  For  applets,  this  security  is  enforced 
through  three  major  components:  the  class  loader,  the 
bytecode  verifier,  and  the  security  manager.  Aglets 
would  require  the  same  level  of  security  as  applets. 
The  aglets  would  need  to  ask  permission  from  the 
security  manager  before  performing  operations,  thus 
allowing  the  security  manager  to  know  the  identity  of 
the  aglet.  For  the  purposes  of  our  paper,  we  are 
exploring  the  utilization  of  aglets  in  support  of  the 
baseline  agent  approach  as  presented  in  Section  2.1 
and  shown  in  Figure  1.  We  have  prototyped  two 
variants  of  the  baseline  agent  approach,  which  differ 
in  the  OSA  allocation  strategies  (see  Section  2.1.3 
again)  and  the  number  of  involved  computing  nodes. 
The  remainder  of  this  section  reviews  the  baseline 
agent  approach  which  we  have  prototyped,  and 
presents  our  assumptions,  messaging  activities,  and 
subsequent  usage  of  the  prototype  in  a  graduate 
course  project. 

3.1  Agent  Implementation  Approach 

The  agent  implementation  effort  of  the  baseline  agent 
approach  is  shown  in  Figure  4.  The  main  difference 
is  a  Translator  that  is  utilized  to  facilitate  message 
passing  communication  between  aglets.  The 
Translator  encodes  the  outgoing  data  from  CA  into  a 
message  (user  request)  that  can  be  passed  to  UA,  and 
retrieves  data  from  the  incoming  message  received  by 
UA  for  the  response  to  the  request.  In  our  prototype,  a 
Translator  is  assigned  to  each  CA/OSA  and  it  is 
responsible  for  translating  data  for  one  user/remote 
object.  In  the  implementation,  the  user’s  identity  is 
included  in  every  message.  The  Translator  on  the 
client  side  acquires  the  responsibility  for 
authorization  that  was  formerly  performed  by  UA. 
The  Translator  on  the  server  side  includes  the  ability 
to  invoke  methods  on  remote  object  methods. 
Whenever  OSA  receives  a  request  from  IRA,  it  passes 
the  message  to  its  Translator.  The  Translator  will 
analyze  the  message,  check  the  permissions  to 
determine  if  the  role  can  access  the  given  method,  and 
if  so,  invoke  the  method  and  create  a  reply  message 
for  OSA  that  is  then  passed  to  IRA.  IRA  moves  back 
to  the  client,  communicates  via  a  message  to  UA, 
which  in  turn  routes  the  response  back  to  CA. 
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Figure  4:  Architecture  for  Agent  Implementation  Approach. 


3.2  Experimental  Prototype 

Based  on  the  framework  described  in  previous 
section,  an  experimental  prototype  was  constructed. 
The  application  involves  typical  university  database 
access  to  courses,  allowing  individuals  to  view,  add, 
delete,  register  or  drop  courses.  There  are  two  roles 
supported:  Faculty  and  Student.  Faculty  has  the 
permissions  to  add,  delete,  and  find  courses.  Student 
can  register,  drop,  and  find  courses.  There  are  two 
remote  objects  in  the  system:  the  Course  database  and 
the  Person  database.  Each  remote  object  contains  data 
and  a  set  of  methods  to  operate  on  the  data.  We 
experimented  with  two  variants  of  the  architecture 
discussed  in  Section  3.1  and  shown  in  Figure  4.  The 
first  variant  placed  the  two  remote  objects,  Course 
database  and  Person  database,  on  the  same  server,  and 
under  the  control  of  a  single,  shared  OSA,  thereby 
supporting  the  first  OSA  allocation  strategy  as  given 
in  Section  2.1.3.  The  second  variant  separated  the  two 
remote  database  objects,  placing  each  on  its  own 
independent  server,  thereby  requiring  two  separate 
dedicated  OSA/Translator  pairs.  Regardless  of  this 


difference,  the  two  versions  utilized  the  same  aglet 
interaction. 

3.3  Assumptions:  OSA  Database  Management 

The  first  variant  of  this  prototype  maintained  the 
Course  and  Person  databases  on  the  same  server, 
thereby  insuring  that  any  change  to  one  database 
affects  the  other  database.  Utilizing  a  shared  OSA  to 
control  the  two  databases  simplified  the  testing  of  the 
system.  Based  on  our  success  with  the  first  variant, 
we  went  forward  to  adopt  a  more  real-world  approach 
in  the  second  variant,  maintaining  the  two  databases 
on  separate  servers.  This  design  requires  dedicated 
OSA/Translator  pairs  to  control  and  manage 
databases  on  discrete  servers.  Associated  dissimilar 
databases  often  are  maintained  on  discrete  systems 
yet  the  integrity  of  their  contents  requires  managed 
manipulations.  Management  by  the  database’s 
OSA/Translator  pair  (see  Figure  4),  removes  the 
dependence  on  the  IRAs  correct  operation,  but 
increases  the  complexity  of  the  servers’ 
implementation.  This  solution  would  be  utilized  if 
numerous  simultaneous  changes  were  to  be  initiated 
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on  the  database.  In  our  second  solution,  the 
management  is  accomplished  by  splitting  the 
responsibility  for  data  integrity  across  databases  into 
the  IRAs.  ERA  submits  a  request  to  either  database 
via  the  OSA.  Upon  confirmation,  from  the 
OS  A/Translator  pair,  a  second  request  is  forwarded  to 
the  other  affected  databases.  Thus,  a  change  in  the 
Course  database  can  be  migrated  to  the  Person 
database  via  the  OSA/Translator. 

3.4  Messaging  for  Aglet  Interactions 

When  the  user  initiates  a  request  via  the  CA,  the 
Translator  (see  Figure  4  again)  is  utilized  to  form  an 
aglet  message.  The  aglet  message  is  a  composition  of 
the  user’s  role  and  parameters  that  comprise  the 
request  (method  invocation)  to  be  performed.  From 
CA,  the  message  sent  out  has  the  type  “request”  with 
an  embedded  message  as  an  argument.  When  UA 
receives  this  message,  it  decodes  the  embedded 
message,  whose  type  is  “taskdescription”,  and 
forwards  the  message  to  its  IRA  agent.  Then  IRA 
agent  obtains  the  context  address  of  the  OSA  from 
that  message  and  then  autonomously  dispatches  itself 
to  the  node  on  which  the  OSA  is  located.  The  OSA 
broadcasts  itself  in  the  aglet  context  by  setting  a 
context  property  as  a  reference  when  it  begins 
execution.  Thus,  when  the  IRA  arrives  in  the  same 
context,  the  IRA  can  locate  which  the  aglet  with 
whom  data  can  be  exchanged. 

For  aglet  programming,  a  mobility  listener  can 
be  established  for  the  aglet.  The  mobility  listener 
defines  the  actions  that  are  going  to  occur  when  the 
aglet  arrives  a  new  place.  A  mobility  listener  is 
attached  to  an  IRA,  and  is  responsible  for  sending 
IRA  the  “asksevice”  message  once  the  IRA  arrives  at 
its  destination.  Thus,  when  the  IRA  receives  a 
message  with  the  “asksevice”  type,  the  IRA  knows 
that  it  has  arrived  at  the  destination.  The  “askservice” 
message  contains  the  user’s  role,  the  request  number 
(method  to  invoke),  and  all  of  the  parameters  of  the 
request.  Using  this  information  IRA  can  communicate 
with  OSA  and  receive  a  reply  message.  The  reply 
message  contains  either  an  error  code  in  the  case  of 
unauthorized  or  unsuccessful  access,  or  the  result 
(success  or  retrieve  data)  of  the  request.  After 
receiving  a  reply  for  OSA,  IRA  dispatches  itself  back 
to  the  originating  node  (client).  When  IRA  arrives 
home,  another  message  with  type  “back”  will  be  sent 
to  IRA  from  its  mobility  listener.  Using  this  message, 
IRA  can  awaken  UA  and  send  the  reply  to  the  request 
for  final  processing  by  UA  before  it  is  returned  to 


CA.  Throughout  the  entire  processing  of  a  request, 
different  messages  are  utilized  to  identify  the  current 
status  of  IRA,  which  along  with  the  mobility  listener, 
allows  IRA  to  move  and  awaken  as  needed. 

3.5  Experimentation  in  Graduate  Course 

During  the  Spring  1999  semester  at  UConn,  the  aglet 
prototype  for  the  baseline  agent  approach  as  shown  in 
Figure  4  and  reviewed  in  Sections  3.1  through  3.4, 
was  the  subject  of  a  course  project  to  explore 
extensibility  and  reuse  of  aglet  software.  The 
students  were  presented  lectures  on  both  role-based 
security  concepts  and  agent  computing  models,  along 
with  an  examination  of  the  concepts  presented  in  this 
paper.  With  this  as  background,  the  students  were 
given  the  aglet  software  consisting  of  1500  lines  of 
Java  code.  While  the  majority  of  the  class  was 
familiar  with  Java,  no  one  in  the  class  had 
programmed  using  agents  and  aglets.  For  the  project, 
the  students  modified  the  agent-based  implementation 
to  includes  a  new  Waiting  List  Agent  (WLA),  which 
is  an  application  specific  agent  that  would  be 
responsible  for  monitoring  the  Course  database  for 
potential  openings  in  full  courses.  The  WLA  would 
be  spawned  by  CA  as  an  option  from  the  GUI.  Once 
spawned,  WLA  would  have  a  limited  life  time  that  is 
either  user  defined  or  tied  to  the  last  day  of  the  add- 
drop  period.  WLA  would  be  a  mobile  agent,  free  to 
move  to  the  processing  node  where  the  course 
database  is  resident.  When  an  individual  drops  a 
course  or  seats  are  added  to  the  course,  WLA  would 
automatically  enroll  the  individual  in  the  course  and 
notify  him/her  by  email.  The  students  implemented 
two  versions  of  WLA: 

•  OSA  Initiated:  In  this  version  of  WLA, 
whenever  updates  to  the  seats  in  a  course  occur, 
the  OSA  can  alert  the  WLA,  which  in  turn  can 
add  the  individual  to  the  course  via  a  path  that 
would  proceed  through  UA  to  IRA  to  OSA  as  per 
the  normal  update  process. 

•  WLA  Initiated:  In  this  version  of  WLA,  WLA  is 
more  autonomous,  and  is  designed  to  periodically 
poll  the  OSA  (via  the  normal  UA  to  IRA  to  OSA 
path).  The  polling  periodicity  would  be  user 
definable.  The  polling  of  OSA  would  ask  if  the 
course  requested  by  CA  has  seats.  If  a  positive 
response  is  received,  the  update  will  proceed  per 
the  normal  process. 

There  is  a  clear  tradeoff  between  the  two 
versions,  the  first  requiring  the  maintenance  of  a 
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list  of  active  WLAs  by  OS  A,  to  allow  the  WLAs 
to  be  contacted,  while  the  second  raises  the 
potential  of  increased  network  traffic  due  to  the 
periodic  polling.  Surprisingly,  all  24  students  in  the 
class  successfully  designed,  implemented,  and 
demonstrated  these  two  new  agents,  with  75%  of  the 
students  able  to  send  email  when  the  course  was 
added  to  a  students  schedule.  In  general,  the  students 
were  able  to  work  within  the  agent/aglet  paradigm 
using  their  knowledge  of  role-based  security  to 
modify  and  extend  the  existing  software. 

4.  Concluding  Remarks  and  Ongoing  Efforts 

Organizations  and  stakeholders  must  be  aware  of 
potential  solutions  that  are  appearing  on  the  horizon 
in  support  of  constructing  dependable  and  secure 
distributed  and  web-based  applications.  One  such 
emerging  technology  is  software  agents,  which  allows 
autonomous  and  mobile  actions  to  occur  in  support  of 
a  new,  dynamic,  computing  paradigm.  Our  work  in 
this  paper  has  emphasized  the  utilization  of  mobile 
and  stationary  agents  to  define  a  set  of  architectural 
approaches  in  support  of  role-based  security  for 
dynamically  accessing  remote  objects.  We  have 
presented  a  baseline  agent  approach  (see  Section  2.1 
again)  that  dispatches  an  agent  to  another  computing 
node  to  access  a  remote  object.  This  baseline 
approach  was  extended  to  handle  complex  requests, 
through  the  addition  of  a  hierarchy  of  agents  (see 
Section  2.2  again)  and  a  object-manager  to  control 
access  to  collections  of  remote  objects  (see  Section 
2.3  again).  The  three  approaches  were  compared  in 
Section  2.4  from  various  dimensions  to  clearly 
understand  under  which  situations  each  approach  is 
most  useful.  Our  successful  prototyping  efforts  of  the 
baseline  approach  utilizing  IBM's  aglet  Java  agent 
system  was  described  in  Section  3.  Overall,  we 
believe  that  agent  approaches  to  security  are  of 
increasing  interest  to  organizations  that  are  involved 
in  web-based  and  distributed  computing  applications, 
and  we  must  begin  to  provide  apropos  security 
solutions. 

Our  ongoing  and  future  efforts  in  this  area 
involve  both  continued  prototyping  and  exploration  of 
agent  architectures.  In  Section  2,  many  different 
allocation  strategies  for  the  different  components  of 
our  agent-security  approaches  were  detailed,  and  the 
prototyping  effort  as  given  in  Section  3  has  only 
discussed  two  variants  of  the  baseline  approach.  We 
are  actively  pursuing  other  variants  so  that  we  can 


more  precisely  understand  the  tradeoffs  in  the 
different  approaches.  This  is  likely  to  be  the  subject 
of  a  future  project  in  a  graduate  course  (see  Section 
3.5  again).  The  architectural  variants  given  in 
Section  2  are  also  being  examined  to  consider  other 
potential  variants  with  different  component 
structures.  Also,  while  we  have  implemented  our 
approach  using  aglets,  there  are  other  Java-based 
agent  platforms  (Voyager,  Concordia,  etc.)  that  are 
candidates  for  prototyping  test-beds.  It  would  be 
interesting  to  compare  and  contrast  the  different  agent 
approaches  for  supporting  role-based  security. 
Finally,  one  glaring  omission  of  our  work  is  the 
realization  of  a  security  policy  for  a  distributed 
setting.  How  is  security  for  clients  defined?  For 
servers?  For  legacy/COTS?  The  ability  to  define, 
realize,  and  enforce  such  a  policy  is  critical  to  insure 
that  agents  implementing  security  are  working  within 
a  defined  and  refined  context. 
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Abstract 


Large  databases  are  increasingly  used  to  manage  sensitive  data;  however,  they  are 
vulnerable  to  abuse  by  insiders  and  intruders.  We  describe  a  novel  method  that  protects 
electronic  records  from  intruders  and  even  the  most  powerful  of  insiders,  the  system 
administrators.  Confidential  data  are  partitioned  and  distributed  after  asymmetric 
encryption  for  management  over  multiple  databases.  Data  splitting  and  distributed 
management  prevent  unauthorized  and  covert  access  by  any  single  party.  Confidential 
systems  using  this  design  can  work  synergistically  with  existing  security  measures  and  are 
suitable  for  health,  genomic,  and  financial  records. 
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1.  Introduction 


Knowledge  is  power  and  large  databases  together  with  new  data  mining  technologies  are 
increasingly  used  to  advance  personal  services  and  scientific  discoveries.  The  public, 
however,  remains  distrustful  of  large  databases  especially  because  of  privacy  concerns.  This 
distrust  delays  the  implementation  of  promising  technology  and  leads  to  economic  and  social 
costs.  A  recent  example  is  the  opposition  to  Iceland’s  national  health  and  genomic  database 
[1,2]. 

According  to  a  1993  U.S.  Congress  Office  of  Technology  Assessment  report,  the  greatest 
threat  to  privacy  of  stored  records  is  by  persons  within  the  system  [3].  This  assessment  is 
supported  by  publicly  known  incidents  of  abuse  by  insiders  [4],  How  to  allow  workers  to 
perform  their  tasks  while  preventing  them  from  abusing  these  privileges  is  the  most  urgent 
subject  for  the  managers  of  these  databases.  It  is  difficult  to  allow  insiders  to  have  the 
privileges  needed  to  perform  their  tasks  while  preventing  the  abuse  of  these  same  powers. 
This  is  especially  true  for  the  powerful  insiders,  such  as  system  administrators,  who  are 
typically  able  to  retrieve  confidential  information  without  detection.  Although  the  system 
administrators  are  not  commonly  perceived  as  the  group  that  is  most  likely  to  perpetrate 
abuse,  this  vulnerability  will  increasingly  gain  significance  as  the  size  and  value  of  the 
database  increase,  and  other  vulnerabilities  are  better  addressed:  Powerful  insiders  will 
increasingly  become  the  weakest  link.  An  important  and  related  threat  comes  from  intruders 
who  obtain  the  system  administrator’s  privileges.  Methods  that  can  prevent  the  abuse  of  the 
system  administrators’  privileges  will  also  function  as  the  last  line  of  defense  against  the 
intruders. 

Current  security  measures  such  as  access  control,  trail  audit  [5],  and 
anonymizing/encryption  offer  little  protection  against  powerful  insiders.  Knowledgeable 
insiders  and  intruders  are  commonly  able  to  bypass  the  access  control  and  trail  audit 
measures.  Insiders  who  have  access  to  the  codebook,  encryption  algorithm,  or  the  un- 
anonymized/un-encrypted  data  entering  or  leaving  the  system  can  defeat  the 
anonymizing/encryption  systems.  For  example,  if  a  codebook  is  used  to  replace  the  names  of 
the  subjects  with  pseudonyms,  the  procedure  can  be  reversed  to  determine  the  names  of  the 
subjects.  If  cryptographic  algorithms  [such  as  one-way  hash  or  asymmetric  algorithms)  are 
used,  insiders  with  access  to  the  cryptographic  algorithms  can  re-identify  the  records  through 
a  trial  encryption  attack  even  if  the  decryption  keys  are  not  accessible  to  the  attacker  [6]. 
Furthermore,  insiders  typically  have  access  to  un-anonymized  or  un-encrypted  data  when  the 
system  performs  the  anonymizing  and  encryption  procedure.  This  is  a  weakness  even  when 
the  encryption  algorithm  is  secured  by  tamper-proof  hardware.  It  is  especially  significant 
when  a  single  coding  unit  is  used  since  the  insiders  at  that  unit  have  access  to  all  secrets 
entering  the  system.  An  example  of  a  system  with  this  vulnerability  is  the  German  cancer 
registry  that  uses  a  central  coding  unit  to  assign  pseudonyms  to  patient  records  [7].  It 
implements  separation  of  duty  between  the  coding  unit  and  three  other  units.  Insiders  at  the 
coding  unit  have  access  to  all  un-anonymized  records  entering  this  system.  Similarly,  an 
U.S.  Air  Force  design  that  relies  on  the  distribution  of  sensitive  data  over  multiple  units 
suffers  the  same  vulnerability  [8].  The  Air  Force  design  uses  a  front-end  unit  to  decompose 
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queries  into  sub-queries,  which  are  sent  to  individual  back-end  databases.  The  back-end 
databases  return  their  output  to  the  front-end  unit  where  they  are  recombined  and  transmitted 
to  the  user.  While  this  design  prevents  the  insiders  at  the  back-end  units  from  discovering 
the  secrets,  the  insiders  at  the  front-end  unit  have  access  to  the  complete  contents  during  both 
the  input  and  output  phases  of  the  transaction. 

An  alternative  to  a  central  anonymizing/encryption  unit  is  a  system  where  the  users 
perform  the  anonymizing  and  encryption.  A  useful  scheme  that  relies  on  distributed 
anonymizing  or  encryption  must  solve  the  problem  of  key  management.  A  useful  multi-user 
system  must  also  provide  centralized  access  control  and  decryption  key  management.  At  the 
same  time,  the  powerful  insiders  charged  with  the  access  control  and  key  management  must 
not  be  able  to  abuse  their  privileges.  To  our  knowledge,  no  existing  design  can  achieve  these 
goals. 

Another  limitation  of  anonymizing/encryption  databases  is  that  obviously  identifiable 
personal  data  such  as  names,  addresses,  and  phone  numbers  cannot  be  maintained  by  the 
system.  More  importantly,  many  other  potentially  identifiable  data  also  cannot  be 
maintained  because  they  can  be  used  to  infer  the  identity  of  records  [9].  In  some 
applications,  the  absence  of  these  data  fields  is  acceptable;  however,  the  “scrubbing”  of  all 
potentially  identifying  data  such  as  date  and  place  of  birth  inevitably  reduces  the  usefulness 
of  the  system.  For  databases  that  maintain  longitudinal  health  records  or  genetic  information, 
it  is  effectively  impossible  to  construct  a  sufficiently  anonymous  database  [2], 

2.  Basic  Design 

We  describe  a  novel  approach  that  uses  data  partitioning,  asymmetric  encryption,  and 
distributed  processing  to  limit  the  power  of  each  powerful  insider.  We  show  that  this  method 
can  be  used  to  implement  centralized  access  control  and  maintain  identifiable  personal  and 
sensitive  data  within  an  enforceable  check-and-balance  system  of  administration. 

Unlike  the  German  cancer  registry  and  the  Air  Force  database  described  previously,  each 
database  unit  in  our  system  has  access  to  only  the  data  needed  to  perform  its  assigned  storage 
and  processing  tasks;  each  unit  does  not  have  access  to  any  other  part  of  the  submitted  data. 
This  strict,  “need-to-know”  data  isolation  is  maintained  by  cryptography  throughout  the  data 
handling  procedure.  Separation  of  duty  is  achieved  through  separate  administration  of  each 
database  unit.  By  partitioning  the  sensitive  data  and  distributing  their  storage  and  retrieval 
over  different  databases,  sensitive  information  is  protected  from  improper  access  by  any  one 
powerful  insider.  Furthermore,  once  fragmented  into  arbitrarily  small  units  and  separated 
from  the  rest  of  the  confidential  record,  all  personal  identifiers  can  be  managed  as  any  other 
elements  of  information. 

Figure  1  shows  an  example  of  how  the  secret  splitting  method  can  be  applied  to  a 
database  containing  personally  identifiable  data.  In  Step  1,  the  User  inputs  a  query  into  a 
client  program.  The  Client  Program  collects  information  to  identify  and  authenticate  the 
user  (subject),  the  client  program,  the  record  of  interest  (object),  and  the  action  to  be 
performed  on  the  record.  The  Client  Program  divides  the  data  to  create  1)  Identifier  sub¬ 
packet  that  conveys  information  needed  to  identify  and  authenticate  the  subject,  object,  and 
the  client  program;  2)  Action  sub-packet  that  contains  the  description  of  the  operation(s)  to 
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be  performed  including  any  new  data  to  be  added.  In  Step  2,  the  Client  Program  first 
encrypts  the  Action  sub-packet  with  a  code  that  is  decodable  only  by  Database  D2;  then,  the 
encrypted  Action  sub-packet  is  combined  with  the  Identifier  sub-packet  and  encrypted  with  a 
code  that  is  decodable  only  by  Database  Dl.  The  output  is  called  the  Original  Request.  In 
systems  where  there  are  more  than  2  database  units,  additional  sub-packets  can  be  the  nested 
within  the  Action  sub-packet.  A  variety  of  encryption  algorithms  can  be  used  so  long  as  the 
sub-packets  can  only  be  decoded  by  each  of  the  intended  databases.  For  example,  a 
symmetric  algorithm  can  first  be  used  to  encrypt  the  sub-packet  and  then  an  asymmetric 
algorithm  used  to  encrypt  the  symmetric  key  (using  the  public  keys  of  Database  Dl  and  D2 
as  appropriate).  Cryptographic  algorithms  and  key  exchange  protocols  have  been  extensively 
reviewed  [10]. 

The  Client  Program  sends  the  Original  Request  to  Database  Dl  where  Database  Dl  (Dl) 
decodes  the  Identifier  sub-packet.  Dl  does  not  have  the  decryption  key  necessary  to  decode 
the  encrypted  Action  sub-packet;  therefore,  the  content  of  the  Action  sub-packet  is 
inaccessible  to  the  system  administrator  of  Dl.  Dl  uses  the  information  from  the  Identifier 
sub-packet  to  (1)  authenticate  the  subject,  (2)  determine  the  access  level  of  the  subject  in 
relation  to  the  object,  and  (3)  determine  the  pseudonym  of  the  object  from  a  Pseudonym 
Table.  The  pseudonym  is  a  code  that  uniquely  represents  the  object.  In  Step  3,  Dl  combines 
the  access  level,  pseudonym  of  the  object,  client  program  identifier,  and  the  encrypted  Action 
sub-packet  to  form  the  Anonymous  Request.  Anonymous  Request  is  encrypted  such  that  it 
is  only  decodable  by  Database  D2. 

Dl  sends  the  Anonymous  Request  to  Database  D2  where  Database  D2  (D2)  decodes  it. 
If  the  subject’s  access  level  permits  the  execution  of  the  operation  specified  in  the  Action 
sub-packet  on  the  specified  object,  D2  performs  the  operation  and  returns  the  results,  if  any, 
to  the  Client  Program.  The  results  can  be  encrypted  for  transmission  to  the  Client  Program 
using  the  public  key  of  the  Client  Program,  the  User,  or  a  special  Session  Key  transmitted  as 
part  of  the  Action  sub-packet. 

In  this  potential  application.  Database  D2  does  not  contain  demographics,  personal,  or 
other  potentially  personally  identifiable  information;  these  identifiers  are  stored  in  Database 
Dl.  The  fragmentation  of  data  diminishes  the  likelihood  of  a  successful  statistical  inference 
attack  on  D2  by  unauthorized  insiders  while  permitting  retrieval  of  the  identifying 
information  by  authorized  users.  Thus,  although  D2  contains  the  list  of  all  patients  with  the 
diagnosis  of  AIDS,  even  the  system  administrator  of  D2  cannot  discover  the  names  of  these 
patients.  The  names  of  the  patients  can  only  be  revealed  when  the  pseudonyms  are  linked  to 
the  names  stored  in  Dl. 

3.  Access  Trail  Logging 

Each  database  unit  maintains  an  activity  log  to  discourage  system  administrators  from 
sending  unauthorized  queries  to  the  system  to  try  to  decode  the  pseudonym  or  to  perform 
unauthorized  data  access.  The  activity  log  at  Dl  records  the  time  of  transmission  from  Dl  to 
D2  and  the  object  of  the  query.  The  activity  log  at  D2  records  the  time  and  object  of  the 
query  and  the  destination  to  which  the  results  were  sent.  When  there  is  a  question  as  to  the 
integrity  of  the  systems,  a  third  party  auditor  can  compare  the  two  logs  to  determine  whether 


85 


there  are  irregularities.  The  preferred  procedure  for  a  third  party  audit  utilizes  a  procedure  to 
transform  these  logs  to  protect  the  confidential  identity  of  the  subject-object  pairs. 

Periodic  reports  can  also  be  generated  by  D1  to  disclose  the  identity  of  all  subjects  who 
accessed  a  given  object.  These  reports  can  be  sent  directly  to  the  owners  of  the  objects  or  to 
an  entity  given  the  responsibility  of  oversight.  Inappropriate  access  of  records  can  thereby  be 
identified  in  a  timely  manner  and  all  participants  held  accountable  for  their  activities. 

4.  Design  Variations 

The  basic  design  in  Figure  1  shows  the  data  flow  from  the  Client  Program  to  a  first 
database  Dl,  onward  to  D2,  and  then  back  to  the  Client  Program.  Other  structural 
organizations  are  possible;  for  example,  additional  databases  can  be  connected  in  multiple 
parallel  and  sequential  layers  to  further  vertically  and/or  horizontally  partition  the  data. 
Various  combinations  and  permutations  of  the  design  can  be  used  to  implement  confidential 
systems  with  performance,  data  integrity,  scalability,  and  security  trade-offs.  The  issue  of 
data  integrity,  for  example,  can  be  addressed  with  a  design  using  redundant  paths  and  subsets 
of  databases  that  manage  error  correction  codes.  Although  the  protection  of  personal 
information  is  an  important  application  of  this  technology,  the  same  protection  method  can 
be  applied  to  non-personal  data. 

5.  Discussion 

As  the  reliability  and  transfer  rate  of  networks  and  cryptographic  engines  continue  to 
increase,  it  will  be  increasingly  feasible  to  trade  performance  for  increased  security  and 
confidentiality.  This  data  management  approach  allows  the  secure  and  confidential  storage 
of  electronic  data  with  little  additional  performance  overhead  since  encryption  during 
transmission  is  already  a  necessary  practice  for  transmission  security.  The  performance 
overhead  is  approximately  one  additional  encryption-decryption  cycle  in  the  most  basic 
design  and  any  additional  setup  time  related  to  the  use  of  two  rather  than  one 
encryption/decryption  procedures.  As  hardware-based  cryptographic  engines  continue  to 
improve,  this  performance  penalty  will  continue  to  diminish.  The  storage  overhead  is  also 
manageable  since  it  is  directly  proportional  to  the  number  of  Subjects  and  Objects. 

The  fragmentation  of  data  into  partitions  has  long  been  used  to  protect  sensitive 
information.  Fundamentally,  cryptographic  algorithms  can  be  viewed  as  methods  of 
fragmentation  (and  recombination)  such  that  the  original  content  can  be  recovered  only  if  the 
fragments  are  recombined.  The  data  fragments  can  be  in  the  form  of  a  decryption  key,  share 
of  secret,  or  cryptotext.  Existing  schemes  uniformly  aim  to  produce  data  fragments  that 
confer  no  information  when  taken  individually  [10].  Our  approach  uses  data  fragments  that 
confer  partial  information  when  taken  individually.  When  these  fragments  are  distributed  to 
multiple  units,  it  is  possible  to  perform  local  processing  using  the  partial  information.  The 
fragmentation  process  prevents  successful  inference  attack  and  precludes  the  need  for 
centralized  decryption  key  management.  In  this  way,  a  powerful  insider  who  controls  any 
given  fragment  is  able  to  perform  the  assigned  tasks  but  unable  to  infer  information  about 
any  other  fragment. 
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To  reduce  the  likelihood  of  improper  access  to  the  un-fragmented  data,  it  is  desirable  to 
split  the  data  as  close  to  the  time  and  place  of  their  creation  as  possible.  Each  Client  Program 
(Figure  1)  splits  sensitive  data  into  fragments  (sub-packets)  where  each  fragment  is  encrypted 
such  that  only  the  intended  database  unit(s)  can  decode  it.  The  data  partitioning  is  achieved 
through  asymmetric  cryptography  to  eliminate  the  need  for  a  secure  channel  for  key 
exchange.  Our  approach  differs  from  traditional  distributed  systems  where  the  distributed 
nature  of  the  architecture  is  hidden  from  the  client  program.  With  our  design,  the  client 
program  uses  destination-specific  information  to  encrypt  and  distribute  the  data  fragments. 
Consequently,  the  client  program  in  our  system  provides  location  and  transaction 
transparency  to  the  users  of  the  system. 

This  work  makes  use  of  a  simple  but  fundamental  principle  -  asymmetric  cryptographic 
algorithms  allow  the  confidential  delivery  of  data  through  insecure  intermediaries  without 
requiring  a  separate  secure  channel  for  key  exchange.  In  this  application,  a  portion  of  each 
query  is  “tunneled”  through  the  set  of  first  databases  to  reach  the  destination  database 
without  disclosing  its  confidential  contents.  In  contrast  with  other  “tunneling”  protocols 
(such  as  in  virtual  private  networking),  our  system  requires  the  intermediate  node(s)  to  be 
equal  partners  and  share  in  the  processing  of  the  transaction.  The  use  of  intermediate  nodes 
as  data  processing  partners  allows  the  system  to  separately  protect  the  fragments  and  the 
links  that  connect  them  to  each  other  across  databases:  a  system  can  be  designed  where  a 
database  unit  manages  only  the  links  between  two  other  database  units. 

Our  secret-splitting  method  differs  from  secret  sharing  schemes  where  each  share  of 
secret  contains  no  information  in  isolation,  and  therefore  each  share  of  data  cannot  be  used  to 
respond  to  a  query  until  the  shares  are  fully  reassembled  [11].  In  contrast,  our  approach 
permits  the  distributed  and  independent  processing  of  the  subqueries  at  each  database  unit 
without  the  need  for  re-assembly.  In  our  system,  re-assembly,  as  the  original  disassembly, 
occurs  in  the  client  program. 

The  ability  to  prevent  abuse  by  powerful  insiders  and  intruders  can  be  instrumental  in 
enabling  the  implementation  of  large-scale  data  collection  and  information-based 
applications.  The  secret-splitting  method  is  potentially  suited  to  the  protection  of  sensitive 
data  such  as  biometrics,  genetic,  health,  and  financial  records.  The  major  vulnerability  of 
this  approach  comes  from  collusion  between  powerful  insiders  of  adjacent  database  units. 
Even  collusion  between  a  user  and  a  powerful  insider  will  only  compromise  the  subset  of 
objects  accessible  to  that  user.  Further  analysis  and  modeling  will  be  needed  to  characterize 
the  relationship  between  variations  in  the  design  and  vulnerability  to  collusion  between  units. 
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Figure  1 .  Basic  Design 
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For  Unknown  Secrecies  Refusal  is  Better  than  Lying 
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A  shared  information  system  is  expected  to  comply  with  the  following  potentially  conflicting  require¬ 
ments.  It  should  provide  useful  answers  to  arbitrary  queries,  while  on  the  other  hand  it  should  preserve  cer¬ 
tain  secrets  according  to  a  security  policy.  We  study  and  compare  two  previously  suggested  approaches  to 
meet  these  requirements,  namely  refusal  of  statements  and  lying.  The  investigation  is  performed  using  a 
highly  abstract  and  general  framework,  both  with  respect  to  the  information  system  and  the  preservation 
of  secrets.  The  assessment  shows  that  for  unknown  secrecies  refusal  is  better  than  lying.  In  particular, 
while  preserving  the  same  secrets  refusal  can  provide  more  useful  answers: 


1  Introduction 

An  information  system  is  commonly  employed  as  a  tool  for  sharing  persistent  data  among 
various  users,  for  supporting  communications  among  these  users,  and  for  deriving  ans¬ 
wers  to  queries  on  the  basis  of  the  stored  data.  In  general,  however,  a  specific  user  has 
only  restricted  rights  to  the  services  of  the  information  system.  In  particular,  query  ans¬ 
wering  on  behalf  of  a  user  can  be  restricted  so  as  not  to  reveal  some  parts  of  the  data 
which  are  considered  to  be  secrets.  Thus  a  shared  information  system  is  expected  to  com¬ 
ply  with  the  following  potentially  conflicting  requirements.  On  the  one  hand  it  should  pro¬ 
vide  useful  answers  to  arbitrary  queries,  while  on  the  other  hand  it  should  preserve 
certain  secrets  according  to  a  security  policy.  We  study  and  compare  two  previously  sugge¬ 
sted  approaches  to  satisfy  these  requirements,  namely  refusal  of  statements  and  lying. 
The  investigation  is  performed  using  a  highly  abstract  and  general  framework,  both  with 
respect  to  the  information  system  and  the  preservation  of  secrets. 

The  information  system  framework  basically  consists  of  the  following  features.  An  instance  of 
the  information  system  is  seen  as  a  structure  of  an  appropriate  logic.  A  query  is  a  sentence  of 
that  logic.  And  finally,  a  query  (sentence)  is  evaluated  with  respect  to  an  instance  (structure)  by 
determining  whether  the  instance  is  a  model  of  the  query  (or,  in  other  words,  whether  the 
query  is  true  in  the  instance). 

The  preservation  of  secrets  framework  basically  consists  of  the  following  features.  A  secret  might 
be  any  sentence  for  which  the  instance  is  a  model.  A  security  policy  states  that  a  given  set  of 
secrets  is  not  allowed  to  be  revealed  to  a  specific  user,  i.e.  the  user  should  not  be  able  to  know 
the  secrets  on  the  basis  of  answers  to  queries.  More  precisely,  for  any  instance  a  secret  is  preser¬ 
ved,  if  for  any  sequence  of  queries  there  exists  an  essentially  different  instance  with  the  follo¬ 
wing  properties:  First,  the  system  produces  the  same  answers  for  the  two  instances,  i.e.,  the 
two  instances  are  indistinguishable  for  the  user.  Second,  while  the  actual  instance  is  a  model 
of  the  secret,  the  other  instance  is  a  model  of  the  negation  of  the  secret. 

Any  approach  to  achieve  preservation  of  secrets  must  be  based  on  some  assumptions  about 
the  user's  capabilities.  In  any  case  these  capabilities  comprise  the  knowledge  about  the  system's 
strategy  to  preserve  secrets,  and  the  system's  answers  to  previous  queries.  Additionally,  before 
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issuing  the  first  query,  the  user  has  some  initial  belief  about  the  instance  which  may  be  true  or 
not.  Thus,  at  any  time  the  user's  current  belief  is  assumed  to  depend  both  on  his  initial  belief 
and  the  system's  answers  to  previous  queries. 

A  first  approach  [10]  to  achieve  preservation  of  secrets  is  based  on  refusal  of  statements,  i.e.  on 
just  returning  a  special  value  (say  mum),  whenever  the  system  recognizes  that  otherwise  a 
secret  would  be  challenged.  A  second  approach  [1]  is  based  on  lying.  Deviating  from  [1],  in 
this  paper  we  use  a  version  of  lying  that  alzoays  requires  to  return  the  negation  of  the  right 
answer  if  a  challenge  is  detected.  This  version  appears  to  be  more  appropriate  within  our  con¬ 
text.  We  study  both  approaches  in  a  unified  framework,  in  order  to  assess  and  to  compare  their 
advantages  and  disadvantages.  The  framework  is  set  up  in  the  tradition  of  previous  work  on 
information  flow  control  and  inference  control,  as  presented  for  example  in  [2, 3, 5, 6, 8, 4]. 

Our  investigations  focus  on  the  case  that  the  user  supposedly  does  not  know  the  secrecies,  i.e. 
the  alternatives  of  a  sentence  and  its  negation  one  of  which  is  the  right  answer  to  be  kept 
secret.  The  insight  gained  in  this  paper  can  be  summarized  by  the  statement  given  as  the  title 
of  the  paper: 

•  For  unknown  secrecies,  refusal  is  better  than  lying. 

•  In  particular,  while  preserving  the  same  secrets  refusal  can  provide  more  useful  answers. 

Formally,  the  insight  only  applies  for  our  general  framework.  This  framework  is  general  in 
the  sense  that  many  reasonable  and  sufficiently  powerful  practical  systems  are  expected  to  be 
specialized  examples.  Thus,  the  insight  widely  remains  valid  also  for  practical  situations. 
Basically,  there  appears  to  be  only  two  ways  to  overcome  the  results.  First,  we  could  consider 
less  powerful  query  facilities  which  do  not  allow  to  submit  any  single  atomic  ground  sentence 
as  a  query.  In  that  case  we  would  have  more  alternatives  than  just  refusal  and  the  simple  form 
of  lying  by  returning  the  negation  of  the  right  answer.  Second,  we  could  relax  our  notion  of 
preserving  a  secret  by  only  requiring  that  its  actual  computation  is  unlikely  to  be  feasible 
within  a  resonable  amount  of  time.  Both  ways  are  beyond  the  scope  of  the  present  paper. 

2  A  simple  example 

This  section  is  intended  to  serve  two  purposes.  It  exemplifies  the  high  level  ideas  and 
claims  surveyed  in  the  introduction.  And  it  illustrates  the  formal  concepts  and  results 
presented  in  the  rest  of  the  paper. 

We  assume  that  the  underlying  logic  of  our  example  information  system  includes  the  atomic 
sentences  a,  b,  si  and  s2,  which  can  be  used  like  propositional  variables.  Suppose  the  actual 
instance  of  the  information  system  is  given  as  an  Herbrand  structure  by 
db  :=  {a,b,  si,  s2}. 

Furthermore,  suppose  that  the  security  policy  requires  not  to  reveal  whether  si  or  — isl 
holds  and  whether  s2  or  -is2  holds.  Later  on  this  requirement  will  be  formally  represen¬ 
ted  by  the  set  of  so-called  secrecies,  i.e.  by 
secrecies  :=  {  {si,  -isl},  {s2,  — is2}  }. 

The  actual  secrets  are  given  by  the  alternatives  that  are  valid  in  the  instance  db,  i.e.  by 
secrets  :=  {si,  s2}. 
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We  will  consider  two  different  runs  of  controlled  query  evaluation  under  both  the  refusal 
approach  and  the  lying  approach.  In  both  runs  the  user  submits  the  sequence  a,  b,  — >s2  of  que¬ 
ries  about  literals,  after  having  got  a  confirmation  about  his  initial  belief.  The  initial  believes  are 
chosen  such  that  they  are  valid  with  respect  to  the  actual  instance  and  do  not  violate  the  secu¬ 
rity  policy  by  themselves.  Thus  for  all  cases,  when  the  initial  belief  is  queried,  then  the  ordi¬ 
nary  query  result  is  returned. 
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comment 

b=>sl 

b=^sl 

b=>sl 

b=>sl 

the  assumed  initial  belief  is  confirmed 
since  no  secret  is  challenged 

a 

a 

a 

a 

no  secret  is  challenged 

b 

b 

mum 

—ib 

otherwise  the  secret  si  could  be  infer¬ 
red  using  the  initial  belief 

— is2 

s2 

mnm 

— is2 

querying  an  alternative  of  a  secrecy 
always  results  in  refusal  or  lying, 
resp. 

Table  2.1  Controlled  query  evaluation  with  initial  belief  b=> si 


Table  2.1  shows  the  first  run,  which  is  for  the  initial  belief  b  =>  si.  The  valid  literal  a  is 
not  at  all  related  to  the  secrets,  and  thus  the  system  can  return  the  ordinary  query  result. 
The  literal  b,  however,  is  just  the  premise  of  the  initial  belief  the  conclusion  of  which,  si, 
is  one  of  the  secrets.  So  the  ordinary  query  result  must  be  modified  by  refusal  and  lying, 
respectively.  Finally,  the  literal  -is2  is  not  valid,  and  thus  the  ordinary  query  result  is  the 
unnegated  alternative,  i.e.  s2.  Surely,  this  result  must  be  modified  too,  since  it  is  a  secret. 


query 

ordinary 
query  result 

answer 

with  refusal 

answer 
with  lying 

comment 

b  =>  si  V  s2 

b  =»  si  V  s2 

b  =>  si  V  s2 

b  =>  si  V  s2 

the  assumed  initial  belief  is  confirmed 
since  no  secret  is  challenged 

a 

a 

a 

a 

no  secret  is  challenged 

b 

b 

b 

— ib 

the  disjunction  of  secrets  (which  is  not 
explicitly  declared  to  be  secret)  can  be 
revealed  under  refusal  but  not  under 
lying 

— is2 

s2 

mum 

. 

— is2 

querying  an  alternative  of  a  secrecy 
always  results  in  refusal  or  lying, 
resp. 

Table  2.2  Controlled  query  evaluation  with  initial  belief  b=> si  V  s2 


Table  2.2  shows  the  second  run,  which  is  for  the  initial  belief  b  =$►  si  v  s2.  The  valid  lite¬ 
ral  a  is  treated  as  before.  Now  the  literal  b  is  the  premise  of  the  initial  belief  the  conclu¬ 
sion  of  which,  si  v  s2,  is  the  disjunction  of  the  secrets.  For  refusal,  at  this  point  of  time, 
there  is  no  need  for  modification  since  this  disjunction  has  not  explicitly  declared  to  be 
secret.  If  later  on  the  disjuncts  happen  to  be  queried  individually  then  the  system  can  still 
refuse  the  ordinary  query  results.  For  lying,  however,  the  system  has  to  proceed  more  cau- 
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tiously:  once  the  user  believes  that  the  disjunction  of  the  secrets  is  valid,  the  system 
cannot  avoid  that  later  on  the  user  can  obtain  a  valid  belief  on  a  secret.  Hence  the  system 
reacts  by  lying.  Finally,  as  in  the  first  run,  — is2  is  not  valid,  and  thus  s2  is  the  ordinary 
query  result.  Surely,  this  result  must  be  modified  too  since  it  is  a  secret.  Fortunately,  the 
lie  about  s2  is  consistent  with  the  previous  lie  about  the  literal  b. 

Comparing  refusal  and  lying  for  the  example  we  can  already  make  some  observations.  The 
formal  investigations  confirm  that  they  also  hold  in  general.  First,  whenever  the  lying 
approach  delivers  the  ordinary  query  result,  so  does  the  refusal  approach.  Second,  sometimes 
refusal  allows  to  return  the  ordinary  result  but  lying  does  not.  Third,  in  general  both  approa¬ 
ches  have  to  postulate  that  the  user  does  not  know  the  secrecies.  For  (our  version  of)  lying, 
this  remark  is  obvious;  for  refusal,  it  can  be  justified  as  follows.  In  the  first  run,  the  system 
refuses  a  statement  about  the  literal  b.  Seeing  the  answer  mum,  the  user  may  examine  why  the 
system  reacts  in  this  way.  If  the  user  knew  that  the  premise  of  his  belief,  b,  is  not  protected  but 
the  conclusion,  si,  he  could  conclude  that  b  must  be  valid.  Otherwise,  there  would  be  no  rea¬ 
son  to  refuse  the  ordinary  query  result.  It  will  turn  out  that  the  refusal  approach  can  be  adap¬ 
ted  to  the  case  that  the  user  knows  the  secrecies,  at  the  price  of  additional  refusals. 

3  Controlled  evaluation  of  queries 

This  section  introduces  our  framework  for  information  systems  and  preservation  of 
secrets. 

3.1  Ordinary  query  evaluation 

An  information  system  maintains  two  kinds  of  data:  A  schema  DS  captures  the  universe 
of  discourse  for  the  intended  application  and  is  formally  defined  as  the  set  of  all  allowed 
instances.  An  instance  db  is  a  structure  which  interprets  the  symbols  of  some  logic,  i.e.  of 
the  universe  of  discourse  (see  e.g.  [9]).  We  only  consider  the  most  elementary  kind  of 
query,  namely  a  sentence  in  the  language  of  the  logic.  Given  a  structure  db  (stored  as  an 
instance)  and  a  sentence  <P  (issued  as  a  query),  0  is  either  true  {valid)  or  false  in  db,  or  in 
other  words,  the  structure  is  either  a  model  of  the  sentence  or  not.  When  a  user  issues  a 
query  <J>  against  the  schema  DS,  the  (ordinary)  query  evaluation  eval{0)  determines  the 
pertinent  case  for  the  current  instance  db.  Thus  we  formally  define 
eval(0) :  DS  — »  {true,  false}  with  eval{0){db )  :=  db  model_of  0 , 
where  the  boolean  operator  model_of  is  assumed  to  be  appropriately  specified  for  the 
logic  under  consideration.  We  also  use  an  equivalent  formalization  where  either  the  que¬ 
ried  sentence  or  its  negation  is  returned: 

eval*{0) :  DS  —>{<£,  with  eval*(0)(db)  :=  if  db  model_of  0  then  0  else  —>0 
Here  as  well  as  in  other  places  we  always  follow  the  convention  that  a  sequence  of  two 
negation  symbols  is  automatically  discarded.  Our  definition  trivially  implies  that  for  all 
instances  db  and  for  all  queries  0  we  have  db  model_of  eval*{0){db). 

We  also  define  the  semantic  relationship  implies  for  logical  implication  in  a  standard  way: 

0  implies  W :iff  for  every  structure  db  with  db  model_of  0  we  also  have  db  model_of  W. 
The  complementary  relationship  is  denoted  with  not_implies. 
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3.2  Inference  control  and  modification  of  query  results 

The  purpose  of  the  inference  control  is  to  ensure  that  an  ordinary  query  result  is  actually 
shown  to  the  user  only  for  those  cases  for  which  this  is  not  considered  to  be  forbidden 
according  to  some  security  policy.  The  parameter  of  the  security  policy  is  declared  as  a  set 
seer  of  secrecies,  each  of  which  consists  of  a  pair  of  complementary  sentences  (f(  -if'}. 
Then  the  policy  states  that  for  every  secrecy  in  seer  the  user  should  not  be  able  to  deter¬ 
mine  —  whether  by  explicit  answers  or  by  inferences  —  which  alternative  of  the  secrecy 
is  correct  (with  respect  to  the  current  instance).  We  define  secrecy(fO  :=  {  %  -if'}.  Each 
set  of  secrecies  seer  uniquely  determines  the  secrets  of  any  particular  instance  db  as 
secrets secr>(ib  :=  { eval*('F)(db )  |  secrecy(fO  e  seer}. 


query  <P.  sentence  of  a  logic 


answer:  possibly  modified  query  result 


Figure  3.1  Schematic  architecture  of  controlled  query  evaluation 

In  order  to  enforce  any  declared  policy  the  system  has  to  make  assumptions  about  the 
user’s  capabilities.  Since,  in  this  scenario,  the  user  is  supposed  to  potentially  behave  as  an 
adversary,  these  assumptions  should  be  as  conservative  as  possible,  and  they  cannot  be 
obtained  by  cooperation  with  that  user.  Our  general  assumptions  will  be  as  follows: 

•  The  user  knows  the  system's  strategy  of  controlled  query  evaluation. 

•  Before  issuing  any  query,  the  user  has  some  initial  belief  about  the  instance. 

•  The  user  remembers  all  answers  to  previous  queries. 

•  The  user  has  unrestricted  computational  power  to  reason. 
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Whenever  the  system  recognizes  that  the  ordinary  answer  to  a  query  would  challenge  a 
secret,  it  basically  has  two  options  to  react: 

•  It  can  refuse  any  substantial  statement  on  the  query,  say  by  returning  the  special  value  mum. 
Refusal  has  been  suggested  in  [10].  The  main  results  will  be  reviewed  in  Section  4. 

•  It  can  lie  in  the  sense  that  it  returns  the  negation  of  the  ordinary  query  result.  Lying  has 
been  suggested  in  [1]  in  a  somehow  different  version  that  is  based  on  secrets  rather  than 
on  secrecies.  The  main  results,  suitably  adopted  for  our  version,  will  be  restated  within 
our  framework  in  Section  5. 

At  first  glance  also  more  sophisticated  forms  of  reactions  appear  to  be  reasonable.  However, 
as  already  discussed  in  [10],  if  the  system  provides  sufficiently  powerful  query  facilities  that 
allow  to  issue  any  single  atomic  ground  sentence  as  a  query,  then,  at  least  in  principle,  a  clever 
user  can  always  challenge  the  system  either  to  refuse  or  to  lie  in  the  simple  form. 

3.2.1  The  security  model 

Having  designed  any  controlled  query  evaluation,  we  have  to  verify  that  the  expected  pro¬ 
perties  of  a  security  model  are  indeed  met.  For  our  investigations  the  security  model  com¬ 
prises  the  following  features: 

•  The  user  issues  sequences  of  queries. 

•  For  any  sequence  of  queries  the  controlled  query  evaluation  should  protect  the  secrets. 

•  The  secrets  should  be  protected  in  the  sense  that  it  is  in  principal  impossible  for  the 
user  to  gain  complete  information  about  the  secrets. 

•  Complete  information  would  mean  that  the  given  query  answers  could  result  from 
exactly  one  choice  for  the  secrets  (i.e.  for  any  secrecy  {%  -iT}  the  pre-image  of  any 
sequence  of  answers  should  contain  at  least  two  essentially  different  instances  which 
differ  for  the  secrecy,  one  of  which  is  a  model  of  %  and  the  other  one  is  a  model  of  — i¥0. 

As  sketched  in  Figure  3.1  the  control  facilities  basically  consist  of  three  components: 

•  The  first  component  is  a  censor,  denoted  by  censor,  which  decides  whether  the  ordinary 
query  result  is  allowed  to  be  shown  to  the  user.  We  study  censors  which  consider  the 
instance  db,  the  secrecies  seer,  the  user  image  user  and  the  query  O.  Thus,  such  a  cen¬ 
sor  returns  a  decision  of  the  form 

censoridb,  seer,  user,  &)  e  {  true  (do  not  show  result),  false  (show  result)}. 

•  The  second  component  is  a  modificator,  denoted  by  modify,  which  possibly  modifies  the 
ordinary  query  result.  For  refusal  we  will  use  the  refusal  modificator  which  constantly 
returns  the  special  value  mum.  And  for  lying  we  will  use  the  lying  modificator  which  always 
returns  the  negated  sentence. 

•  The  third  component  is  the  user  image,  denoted  by  user,  which  contains  the  system’s 
explicitly  represented  assumptions  on  the  user’s  belief  about  the  instance.  The  user 
image  is  just  a  set  of  sentences  in  the  language  of  the  logic.  We  will  allow  the  user 
image  to  be  initialized  more  or  less  freely,  and  for  each  query  the  returned  answer  is 
inserted  but  only  if  that  answer  is  a  sentence  in  the  logic. 
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Since  the  controlled  evaluation  has  to  keep  track  of  both  the  initial  belief,  user0,  and  the  pre¬ 
vious  answers,  a  sequence  of  queries  is  processed  using  a  memory.  Thus,  for  each 

(<£>;,...,0")  and  user0  we  consider  a  function 

control_eval(  user0 ) 

which  is  formalized  by  an  inductive  definition  of  the  form: 

control_eval(  (&1  ,...,Qd),  user0  )(db,  seer)  :=  ( (arts1,  user1),...,(ansn,  user n) )  with 
ansl:=  if  censor(db,  seer,  used'1,  <&)  then  modify{eval*(<&)(db ))  else  eval*(<&)(db), 

used  :=  if  ans1  is  a  sentence  then  used'1  u  { ans 1  }  else  used'1. 

Any  specific  approach  is  determined  by  the  local  functions  censor  and  modify. 

4  Refusal  of  statements 

Controlled  query  evaluation  with  refusal  treats  queries  according  to  the  following  rules: 

•  It  delivers  the  ordinary  query  result  if  no  secret  is  challenged. 

•  Otherwise  it  refuses  to  give  a  statement  by  using  the  refusal  modificator. 

•  It  maintains  a  user  image  user  with  "true  beliefs",  i.e.  we  always  have  db  model_of  user. 

•  Accordingly,  for  the  functions  control_eval(  (&1,. user0 )  only  those  arguments  (db, 
seer)  are  "allowed"  which  satisfy  the  precondition  db  model_of  user0. 

Obviously  we  can  only  protect  secrets  which  are  not  already  initially  believed.  Hence  we  are 
interested  in  ensuring  the  invariant  for  real  secrets: 

used  not_implies  X,  for  all  Xs  realsecrets,  where 

realsecrets  :=  {  X  \  user0  not_implies  X  and  db  model_of  X  and 

secrecy(-X)  e  seer}. 

The  main  results  of  [10]  about  controlled  evaluation  with  refusal  are  restated  in  the  next  sub¬ 
sections.  They  can  be  basically  summarized  as  follows: 

•  With  regard  to  a  modelled  user  who  does  not  know  the  secrecies:  for  preserving  secrets 
under  all  sequences  of  queries,  it  is  necessary  and  sufficient  that  the  censor  maintains  the 
invariant  for  real  secrets.  This  property  is  just  achieved  by  the  secret  censor. 

•  With  regard  to  a  modelled  user  who  is  aware  of  the  secrecies:  for  preserving  secrets  under 
all  sequences  of  queries,  it  is  necessary  and  sufficient  that  the  censor  maintains  a  stronger 
invariant  —  one  that  protects  any  sentence  of  the  secrecies  under  arbritrary  answers.  This 
property  is  just  achieved  by  the  secrecy  censor. 

4.1  The  secret  censor 

Firstly,  we  define  and  study  the  secret  censor.  The  secret  censor  demands  that  the  ordi¬ 
nary  query  result  be  modified  if  the  user  could  use  the  correct  result  eval*(0)(db )  to  infer 
a  secret  *F ,  i.e. 

censor secrets(db,  seer,  user,  &)  := 

(exist  *F)[db  model_of  *Fand  secrecy(¥9  6  seer  and 
user  u  {  eval*(<P)(db)  }  implies  IF] . 
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Theorem  4.1  below  is  based  on  the  assumption,  that  the  user  does  not  know  the  secrecies. 
Theorem  4.2  below  shows  that  this  assumption  is  indeed  crucial  since  otherwise  the  user  can 
possibly  take  advantage  of  refusals  (which  are  not  explicitly  represented  in  the  user  image). 

Theorem  4.1  [succesful  refusal  when  secrecies  are  unknown] 

Let  censor  be  the  secret  censor  and  modify  be  the  refusal  modificator,  (.P1  be  an 

arbitrary  sequence  of  queries  and  user0  be  an  arbitrary  initial  belief.  Then  for  all  “allo¬ 
wed"  arguments  ( db_l ,  secr_l)  and  for  all  real  secrets  X  with  user0  not_impli.es  X  and 
db_l  model_of  X  and  secrecy(X)  €  secr_l,  there  exists  a  different  “allowed"  argument 
(db_2,  secr_2)  with  the  following  properties: 

(a)  [same  answers] 

control _eval((<P1  user0  ){db_l,secr_l)  =  control _eval{(,&1  ,...,<2^),  user0  ){db_2,secr_2 ); 

(b)  [different  secrets]  eval*(X)(db_l)  *  eval*{X){db_2). 

Proof 

Basically,  this  theorem  is  Theorem  10.3  from  [10].  So  we  only  sketch  the  proof.  According 


to  the  assumption,  the  real  secret  Xhas  the  properties 

db_l  model_of  X  and  (4.1) 

user0  no t_implies  X.  (4.2) 

Since  the  secret  censor  maintains  the  invariant  for  real  secrets,  we  also  have  for  the  final 
belief  that 

user_l n  no t_impl ies  X .  (4.3) 

Then,  by  the  usual  definition  of  implies,  there  exists  a  structure  db_2  such  that 

db_2  model_of  user_ln  and  (4.4) 

db_2  model_of  —X.  (4.5) 

We  take  db_2  as  the  new  instance,  and  we  define  the  new  secrecies  as 

secr_2  :=  {secrecy(  eval*(<P){db_2)  a  user |  (4.6) 


censor secrets{db_l ,  secr_l,  user <&) }, 

where  “a  user_ll'lu  abbreviates  the  conjunctive  addition  of  the  conjunction  of  all  elements 
of  user The  new  argument  ( db_2 ,  secr_2 )  has  the  properties  stated  in  the  theorem: 

•  The  argument  ( db_2 ,  secr_2)  is  "allowed"  by  (4.4)  and  since  user0  c  user_ln. 

•  Property  (b)  results  from  (4.1)  on  the  one  side,  yielding  eval*{X){db_l)  =  X ,  and  (4.5)  on 
the  other  side,  yielding  eval*(X)(db_2)  =  -X. 

•  Property  (a)  can  be  verified  by  an  induction  on  the  sequence  number  i  of  the  query. 

□ 

In  order  to  give  an  example  how  in  the  proof  of  Theorem  4.1  the  different  argument  (db_2, 
secr_2)  is  actually  constructed  we  reconsider  the  simple  example  displayed  in  Table  2.1. 
Using  the  notations  of  the  theorem  we  start  with  user0  :=  {b=>sl},  db_l  :=  {a,  b,  si,  s2}, 
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secr_l  :=  {  {si,  -isl},  {s2,  — is2}  }  and  X  :=  si.  When  processing  the  query  sequence  a,  b, 
-is2  the  system  generates  the  user  images  user1  :=  {b=>sl,  a},  user2  :=  (b=>sl,  a}  and 
user3  :=  {b=>sl,  a}.  Then,  for  example,  we  can  take  db_2  :=  {a,  — >b,  -isl,  -is2}  as  the  new 
instance.  Finally,  the  new  secrecies  are  defined  as 

secr_2  :=  {  secrecy(— ib  a  b=>sl  a  a),  secrecy(— >s2  a  b=>sl  a  a)  }  . 

The  resulting  new  secrets  are 

secrets_2  :=  {  — ib  a  b=>sl  a  a,  — is2  a  b=>sl  a  a  }  . 

When  under  the  same  initial  belief  the  same  query  sequence  is  evaluated  with  respect  to 
the  new  argument  ( db_2 ,  secr_2)  then  we  indeed  get  the  same  answers.  For  the  first 
query,  a,  the  ordinary  query  result,  a,  is  returned,  since  {b=»sl,  a}  does  not  imply  any 
new  secret.  For  the  second  query,  b,  the  statement  is  refused,  since  the  ordinary  query 
result,  — ib,  together  with  the  current  user  image,  {b=>sl,  a},  would  reveal  the  first  new 
secret.  Similarly,  the  statement  is  refused  for  the  third  query,  — is2. 

Theorem  4.2 

Let  censor  be  the  secret  censor  and  modify  be  the  refusal  modificator.  Then  there  exists  a 
sequence  of  queries  ((P1,...,#1),  an  initial  belief  user0  and  a  set  seer  of  secrecies  with  the 
following  properties: 

there  exists  a  sequence  of  query  answers  such  that  its  pre-image  for  the  function 
control_eval{  user1)  with  respect  to  instances  only  —  fixing  the  secrecies  — 

contains  exactly  one  element  (up  to  query  equivalence  of  instances) 

Proof 

Basically,  this  theorem  is  implicitly  stated  in  Section  4  of  [10].  □ 

The  theorems  also  show  that,  at  least  in  general,  the  user  cannot  determine  initially 
unknown  secrecies  from  the  answers,  since  otherwise  he  could  first  do  so  and  then  use  a 
reasoning  like  in  the  (omitted)  proof  of  Theorem  4.2  to  determine  also  the  secrets.  But 
this  method  would  contradict  Theorem  4.1. 

4.2  The  secrecy  censor 

Secondly,  we  define  and  study  the  secrecy  censor.  The  secrecy  censor  demands  that  the 
ordinary  query  result  be  modified  if  the  user  could  use  an  arbitrary  answer  to  infer  a 
secret  or  its  negation,  i.e. 

censor secrecies(db,  seer ,  user,  &)  := 

(exist  ¥)  [  db  model_of  ¥  and  secrecy(*f/)  e  seer  and 
[  user  u  {eval*(<P)(db)}  implies  ¥  or 
user\j  {  —eval*(<P)(db)}  implies  ¥  or 
userKj  {  —eval*(<P)(db)}  implies  -*¥  ]  ]. 

Obviously  the  secrecy  censor  is  stronger  than  the  secret  censor.  In  particular  the  secrecy  cen¬ 
sor  maintains  a  strengthened  invariant  for  secrecies: 

•  user 1  no t_impl  ies  X,  for  all  X  e  realsecrets,  and  additionally  if  ans1  *  mum 
user1'1  u  {  —ans1}  not_implies  X,  for  all  Xwith  secrecyCX)  e  seer. 
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Theorem  4.3  below  states  that  controlled  evaluation  with  refusal  based  on  the  secrecy- 
censor  prevents  a  user  who  knows  the  secrecies  to  gain  complete  information  about  a 
secret.  Thus  the  theorem  also  confirms  that  there  is  no  need  to  explicitly  represent  refu¬ 
sals  in  the  user  image. 

Theorem  4.3  [successful  refusal  when  secrecies  are  known] 

Let  censor  be  the  secrecy  censor  and  modify  be  the  refusal  modificator,  (01,...,<&l)  be  an 
arbitrary  sequence  of  queries  and  user0  be  an  arbitrary  initial  belief.  Furthermore  let  seer 
be  a  fixed  set  of  secrecies.  Then  for  all  instances  db_l  such  that  ( db_l ,  seer )  is  an  “allowed* 
argument  and  for  all  real  secrets  Xwith  user0  not_implies  X and  db_l  model_of  X and 
secrecy(X)  e  seer,  there  exists  a  different  instance  db_2  such  that  ( db_2 ,  seer)  is  “allo¬ 
wed"  with  the  following  properties: 

(a)  [same  answers] 

control_eval(  (0I,...,0^),  user0  )(db_l,  seer)  =  control_eval(  {01  user0  )(db_2,  seer)  ; 

(a)  [different  secrets]  eval*(X)(db_l)  *  eval*(X)(db_2). 

Proof 

Basically  this  is  Theorem  10.2  from  [10].  The  proof  is  similar  to  the  proof  of  Theorem  4.1.  □ 

5  Lying 

Controlled  query  evaluation  with  lying  treats  queries  according  to  the  following  rules: 

•  It  delivers  the  ordinary  query  result  if  no  secret  is  challenged. 

•  Otherwise  it  lies  by  using  the  lying  modificator  modify (0)  :=  -i<2> . 

•  It  maintains  a  user  image  user  which  consists  of  a  belief,  i.e.  a  set  of  sentences  for 
which  the  instance  db  might  be  a  model  or  not. 

•  However,  the  function  control _eval{  (01,. ..,<&*),  user0 )  will  be  considered  only  for  consi¬ 
stent  initial  beliefs  user0.  It  appears  to  be  intuitively  unreasonble  to  assume  that  a 
user  believes  an  inconsistent  set  of  sentences,  and  each  such  set  would  have  the  for¬ 
mal  porperty  that  it  implies  any  sentence  and  hence  also  all  secrets. 

Surely,  controlled  query  evaluation  should  maintain  consistency  of  user  belief  as  an  inva¬ 
riant.  However,  this  requirements  cannot  always  be  achieved  if  for  any  query  a  pertinent 
though  possibly  lied  statement  is  returned.  The  following  example  characterizes  the 
situation.  Define  secrets  :=  }  and  user0  :=  {f^  v...v¥^  }.  If  the  user  issues  the 

sequence  of  queries  then  the  ordinary  query  results,  namely  must  be  modi¬ 

fied,  i.e.  the  lying  modificator  generates  the  answers  -I’Fj.  Hence  we  finally  get  the  user 
belief  user*  :=  (f)  v...v^  ,  — },  which  clearly  is  inconsistent. 

The  final  event,  that  the  user  belief  becomes  inconsistent  after  k  answers,  is  closely  related  to 
the  directly  preceding  event,  that  the  still  consistent  user  belief  after  k-1  answers  logically 
implies  the  last  secret.  For  consider  that  user  belief  user*'1  :=  {IFj  v...vlFfc ,  ->xfr1,...,-xxFk_-L  }: 
clearly  we  have  user*'1  implies  .  Hence  the  initial  belief  and  the  first  k-1  answers  (lies) 
would  reveal  the  last  secret  . 
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The  example  indicates  that  in  general  it  is  necessary  to  maintain  a  strengthened  invariant  that 
not  only  preserves  the  consistency  of  the  user  belief  but  also  the  assertion  that  the  user  belief 
does  not  imply  the  disjunction  of  all  secrets  (which  clearly  includes  the  consistency). 

The  more  precise  investigations  below  will  provide  a  main  result  that  can  be  basically  sum¬ 
marized  as  follows: 

•  With  regard  to  a  modelled  user  who  does  not  know  the  secrecies:  for  preserving  secrets 
under  all  sequences  of  queries,  it  is  necessary  and  sufficient  that  the  initial  belief  does 
not  imply  the  disjunction  of  all  secrets  and  that  the  censor  maintains  the  correspon¬ 
ding  invariant.  This  property  is  just  achieved  by  the  secret-disjunction  censor. 

5.1  The  secret-disjunction  censor 

The  secret-disjunction  censor  demands  that  the  ordinary  query  result  be  modified  if  the 
user  could  use  the  correct  result  to  infer  the  disjunction  of  all  secrets,  i.e.  with 
secret _disjunction  :=  •f'j  v...v^  for  secrets  :=  {  },  in  particular 

secret _dis junction  :=  0  for  secrets  :=  0, 

define 

censor secdisJ{db,  seer,  user,  <P)  :=  user  u  {  eval*(<P)(db)  }  implies  secretjdisjunction. 

Then,  together  with  the  lying  modificator  modify  (0) -id>,  by  instantiating  the  generic  declara¬ 
tion  given  in  Section  3.2.1,  we  get  controlled  query  evaluation  with  lying  as 

control _eval{  (0I,...,0l),  user0  )(db,  seer )  :=  ( ( ans 1,  user1),. ..fans'1,  user n) )  with 
ans1  :=if  censor secdisj{db,  seer,  user1'1,  <ff)  then  -eval*(<ff)(db)  else  eval*(<P)(db), 
user1  :=  user1’1  \j  {ans1 }. 

Theorem  5.2  below  describes  the  situation  when  controlled  query  evaluation  with  lying  achie¬ 
ves  the  required  kind  of  security.  In  preparation  for  this  result.  Theorem  5.1  below  first  shows 
that  the  necessary  invariant  for  the  disjunction  of  all  secrets  is  indeed  maintained.  Both  theo¬ 
rems  together  say  that  the  invariant  is  also  sufficient  for  preserving  the  secrets.  These  theorems 
are  related  to  the  assertions  in  Section  V  of  [1],  which  were  made  there  within  a  model-theore¬ 
tic  framework  for  a  modal  logic  of  belief  and  for  a  version  of  lying  based  on  secrets  rather 
than  on  secrecies. 

Theorem  5.1  [Invariant  of  the  secret-disjunction  censor] 

Let  censor  be  the  secret  disjunction  censor  and  modify  be  the  lying  modificator.  Then  con¬ 
trolled  query  evaluation  with  lying  has  the  following  property: 
user1’1  not_implies  secretjdisjunction 
if  and  only  if 

user1  not_implies  secretjdisjunction. 

Proof 

The  claim  immediately  follows  from  user1'1  c  user1. 

Assume 

user1'1  not_implies  secretjdisjunction. 


(5.1) 


and  let  <&  be  an  arbitrary  query.  According  to  the  definition  of  the  controlled  query  eva¬ 
luation  with  lying,  the  returned  answer  ans1  is  either  eval*(<&)(db )  or  ~eval*(<&)(db),  and 
this  answer  is  added  to  used'1 . 

Case  1:  ans1  -  eval*(<&)(db). 

This  case  happens  if  and  only  if  the  secret-disjunction  censor  delivers  false,  i.e.  if  used'1  u 
{  eval*(<P)(db)  }  not_implies  secretjiisjunction.  The  latter  relationship  is  just  the  claim. 
Case  2:  ans1  =  -» eval*(<fi)(db). 

This  case  happens  if  and  only  if  the  secret-disjunction  censor  delivers  true,  i.e.  if 


used'1  kj  {  eval*(&)(db)  }  implies  secretjiisjunction  (5.2) 

Now  suppose  indirectly  that  we  also  have 

used'1  u  {  — i eval*(<&)(db)  }  implies  secretjiisjunction.  (5.3) 

Then,  by  a  well-known  result  of  logic,  (5.2)  and  (5.3)  are  only  possible  if  even 

used'1  implies  secretjiisjunction.  (5.4) 

This  relationship,  however,  contradicts  assumption  (5.1).  □ 

Theorem  5.2  [successful  lying  when  secrecies  are  unknown] 


Let  censor  be  the  secret-disjunction  censor  and  modify  be  the  lying  modificator,  (<£*,„., <£") 
be  an  arbitrary  sequence  of  queries  and  user 0  be  an  arbitrary  initial  belief.  Then  for  all 
arguments  ( db_l ,  secr_l )  with  user0  not_implies  secret_disjunction_l  and  for  all 
secrets  A  with  db_l  model_of  Xund  secrecy (X)  e  secr_l,  there  exists  a  different  argu¬ 
ment  ( db_2 ,  secr_2 )  with  the  following  properties: 

(a)  [same  answers] 

control jvalijO1  user0  ){db_l,secr_l)  -  controljvaUiO1,...,#1),  user0  )(db_2^ecr_2) ; 


(b)  [different  secrets]  eval*(X)(db_l)  *  eval*(X)(db_2). 

Proof 

Setting  user_l°  =  user0  we  have  by  assumption 

user_l°  not_implies  secret _disjunction_l  (5.5) 

and  hence,  by  Theorem  5.1  about  the  invariant,  also 

user_ln  not_impli.es  secret jiisjunction_l.  (5.6) 

Since  X e  secrets_l  and  thus  X implies  secret _disjunction_l, from  (5.6)  we  obtain 

user_ln  not_implies  X.  (5.7) 

Then,  by  the  usual  definition  of  implies,  there  exists  a  structure  db_2  such  that 

db_2  model_of  user_ln,  (5.8) 

db_2  model_of  —X .  (5.9) 

We  take  db_2  as  the  new  instance,  and  we  define  the  new  secrecies  as 

secr_2  :=  0.  (5.10) 
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(5.11) 


Hence  we  have 

secret _dis junction _2  :=  0. 

Then  we  show  that  the  new  argument  ( db_2 ,  secr_2)  has  the  properties  stated  in  the  theorem: 

•  Property  (b)  results  from  the  assumption  db_l  model_of  X  on  the  one  side,  yielding 
eval*(X)(db_l)  =  X,  and  from  (5.9)  on  the  other  side,  yielding  eval*(X)(db_ 2)  =  ->X. 

•  Property  (a)  can  be  verified  by  an  induction  on  the  sequence  number  i  of  the  query. 

□ 

In  order  to  give  an  example  how  in  the  proof  of  Theorem  5.2  the  different  argument  ( db_2 , 
secr_2)  is  actually  constructed  we  reconsider  the  simple  example  displayed  in  Table  2.1. 
We  start  with  user0  :=  {b=>sl},  db_l  :=  {a,  b,  si,  s2},  secr_l  :=  {  {si,  -isl},  {s2,  ->s2}  } 
and  X  :=  si.  When  processing  the  query  sequence  a,  b,  -is2  the  system  generates  the  user 
images  user1  :=  {b=>sl,  a},  user2  :=  {b=>sl,  a,  -ib}  and  user 3  :=  {b=>sl,  a,  -ib,  -is2}. 
Then  we  have  to  take  db_2  :=  {a,  -ib,  -isl,  — >s2}  as  the  new  instance.  Finally,  the  new 
secrecies  are  defined  as  secr_2  :=  0  .  Since  the  new  argument  has  no  secrets,  the  system 
will  always  return  the  ordinary  query  result.  Accordingly,  when  under  the  same  initial 
belief  the  same  query  sequence  is  evaluated  with  respect  to  the  new  argument  ( db_2 , 
secr_2)  then  we  indeed  get  the  same  answers. 

6  Assessment  of  refusal  and  lying 

In  Table  6.1  we  summarize  the  properties  of  the  approaches  to  controlled  query  evalua¬ 
tion  as  treated  in  this  paper.  Before  we  start  the  final  assessment,  we  emphasize  two  fea¬ 
tures.  First,  the  controls  should  preserve  the  secrets  uniformly,  i.e.  for  all  possible 
sequences  of  queries  and  user  images,  and  for  all  “allowed"  arguments  the  controls  should 
be  performed  with  the  same  security  mechanisms  (the  censor  and  the  modificator  in  par¬ 
ticular).  Preserving  secrets  means,  here,  that  in  all  cases  the  user  cannot  uniquely  deter¬ 
mine  the  secret  part  of  the  current  instance.  Secondly,  this  property  holds  even  if  the  user 
can  employ  unrestricted  computional  power.  For,  whatever  sequence  of  queries  is  issued 
and  whatever  initial  belief  is  available,  the  evaluation  function  turns  out  to  be  “nowhere 
injective  with  respect  to  the  secrets",  as  far  as  it  is  succesful.  Therefore,  the  following 
assessment  applies  for  uniform  controls  to  defend  against  unrestricted  users. 

Refusal  using  the  secret  censor  has  the  following  advantages  in  comparison  to  (our  version  of) 
lying  using  the  secret-disjunction  censor: 

•  Refusal  is  applicable  for  a  larger  class  of  normal  arguments,  because  the  condition  for 
the  secret  censor  is  weaker  than  the  condition  for  the  secret-disjunction  censor. 

•  More  generally,  the  secret  censor  is  weaker  than  the  secret-disjunction  censor,  and 
thus  the  former  more  often  shows  the  ordinary  query  result  than  the  latter. 

•  By  refusal,  the  user  is  never  misled  by  lying. 

•  Refusal  can  be  combined  with  a  stronger  censor,  the  secrecy  censor,  in  order  to  cope 
with  applications  where  the  secrecies  are  supposedly  known  to  the  user. 
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Refusal  with 

Refusal  with 

Lying  with 

secret  censor 

secrecy  censor 

secret-disjunction 

censor 

censor 

censorship,  if  current  user 
belief  and  (correct)  ordinary 
query  result  imply  a  secret 

censorship,  if  current  user 
belief  and  arbitrary  result 
imply  a  secret  or  its  nega¬ 
tion 

censorship,  if  current  user 
belief  and  (correct)  ordinary 
query  result  imply  the  dis¬ 
junction  of  all  secrets 

modificator 

refusal  modificator: 
modify  ()  =  mum 

refusal  modificator: 
modify  ()  =  mum 

lying  modificator: 
modify(0)  =  -><£ 

user  image 

user  belief  user  with 
db  model_of  user 

user  belief  user  with 
db  model_of  user 

user  belief  user  with 

user  consistent 

pre¬ 

condition 

argument  allowed: 
db  model_of  user0 

argument  allowed: 
db  model_of  user0 

initial  user  belief  user 0  does 
not  imply  the  disjunction 
of  all  secrets 

exceptional 

case 

initial  user  belief  user0 
implies  a  secret,  and  thus 
all  statements  are  refused: 

initial  user  belief  user0 
implies  a  secret,  and  thus 
all  statement  are  refused: 

initial  user  belief  user0 
implies  the  disjunction  of 
all  secrets  (in  particular  the 
initial  belief  user0  is  incon¬ 
sistent): 

mechanism  not  applicable 

mechanism  not  applicable 

mechanism  not  applicable 

normal  case 

initial  user  belief  user0  does 
not  imply  any  secret 

initial  user  belief  user 0  does 
not  imply  any  secret 

initial  user  belief  user0  does 
not  imply  the  disjunction  of 
all  secrets  (and  thus  is  not 
inconsistent) 

invariant  in 
the  normal 

case 

user  belief  user  does  not 
imply  any  secret 

user  belief  user  does  not 
imply  any  secret  or  its 
negation,  even  if  the  last 
nonrefused  ordinary  query 
result  is  substituted  by  its 
negation 

user  belief  user  does  not 
imply  the  disjunction  of  all 
secrets 

secrecies 

known 

secrets  cannot  be 
preserved: 

Theorem  4.2 

secrets  can  be  preserved: 

Theorem  4.3 

secrets  cannot  be 
preserved: 
obvious 

secrecies 

unknown 

secrets  can  be  preserved: 
Theorem  4.1 

secret s  can  be  preserved: 
Theorem  4.3 

secrets  can  be  preserved: 
Theorem  5.2 

Table  6.1  Assessment  of  uniform  control  mechanisms  to  defend  against  unrestricted  users 


However,  there  also  could  be  two  disadvantages: 

•  The  precondition  of  refusal  is  stronger  than  the  precondition  of  lying.  The  former 
requires  that  the  assumed  initial  belief  is  compatible  with  the  actual  instance,  whe¬ 
reas  the  latter  only  demands  its  consistency. 

•  Refusal  reveals  the  pure  fact  of  modification  (but  neither  the  specific  reasons  behind 
the  refusal  nor,  in  particular,  the  secrecies)  whereas,  of  course,  lying  is  not  indicated. 

In  conclusion,  for  the  majority  of  applications  we  expect  that  the  advantages  of  refusal  will  be 

ranked  higher  than  its  disadvantages.  Therefore,  in  general  we  favour  refusal  over  lying. 
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There  are  several  directions  for  further  interesting  research.  We  only  mention  a  few  of  them. 
First,  we  could  relax  the  two  features  emphasized  above.  So  we  could  include  less  uniform 
and  thus  more  sophisticated  mechanisms,  and  we  could  try  to  protect  secrets  based  on  the 
restricted  computational  power  of  users.  Second,  we  could  investigate  how  to  combine  refu¬ 
sal  and  lying  and  possibly  even  other  types  of  reactions,  in  particular  for  nonuniform  mecha¬ 
nisms  to  defend  against  restricted  users.  Third,  we  could  extend  the  comparison  for  the 
original  version  of  lying  that  assumes  that  the  user  knows  that  a  fixed  set  of  secrets  (not 
secrecies)  are  to  be  kept  secret.  We  conjecture  that  the  original  version  is  closely  related  to 
refusal  with  the  secrecy  censor.  Fourth,  we  could  study  appropriate  instantiations  of  modal 
logic,  their  expressiveness  and  the  complexity  of  their  decison  problems,  for  reasoning  about 
the  belief  of  users  from  the  point  of  view  of  the  protecting  system.  Fifth,  we  could  refine  the 
investigation  for  more  practical  versions  of  information  systems.  The  previous  work  on  lying 

[1]  and  the  study  in  [4]  are  examples  of  useful  starting  points  for  the  last  two  suggestions. 
Finally,  it  would  be  worthwhile  to  embed  the  present  and  future  work  into  the  general  theory 
of  Reasoning  about  Knowledge  as  elaborated  in  [7]. 
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Abstract 

Bertino,  Ferrari  and  Atluri  (BFA)  have  recently  presented  a  model  for  specifying  and 
enforcing  authorization  constraints  for  Workflow  Management  Systems  (WFMS).  The 
model  is  comprehensive  and  exhibits  strong  properties  such  as  (1)  a  language  to 
express  constraints,  (2)  formal  notions  of  constraint  consistency  and  (3)  algorithms  for 
role-task  and  user-task  assignments.  In  this  paper,  we  extend  the  BFA  model  to  include 
primitives  for  weighted  voting.  We  show  that  the  BFA  model  cannot  express  weighted 
voting  in  a  straightforward  manner,  whereas  Transaction  Control  Expressions  (TCEs) 
proposed  by  Sandhu  [5]  incorporates  this  notion.  Since,  all  other  aspects  of  TCEs  can 
be  easily  simulated  in  BFA,  we  believe  that  the  notion  of  weighted  voting  is  a 
fundamental  operation  which  is  missing  in  the  BFA  model.  Although,  we  do  not  formally 
prove  that  BFA  cannot  simulate  weighted  voting,  we  make  a  strong  case  that  this  cannot 
be  done  easily  or  directly.  We  also  show  that  the  extended-BFA  model  retains  all  the 
strong  properties  of  the  BFA. 
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1.  Introduction 

In  recent  years,  workflow  management  systems  (WFMSs)  have  gained  popularity  both  in 
research  and  commercial  sectors.  WFMSs  are  used  to  coordinate  and  streamline 
business  processes  of  an  enterprise.  A  workflow  separates  the  various  activities  of  an 
enterprise  into  well-defined  tasks.  The  tasks  in  a  workflow  are  usually  carried  out  by 
users  according  to  organizational  rules  relevant  to  the  process  represented  by  the 
workflow.  The  security  requirements  imposed  by  these  workflow  applications  calls  for 
suitable  access  control  mechanisms.  An  access  control  mechanism  enforces  the 
security  policy  of  the  organization.  Typically  a  set  of  authorizations  express  this  security 
policy.  This  is  carried  out  by  performing  a  check  against  the  set  of  authorizations  to 
determine  if  a  user  intending  to  execute  a  given  task  on  a  specified  object  is  actually 
authorized  for  it. 

Quite  often,  security  policies  of  a  given  organization  are  expressed  in  terms  of  roles 
within  the  organization  rather  than  individual  users.  Roles  represent  organizational 
agents  intended  to  perform  certain  job  functions  within  the  organization.  Users  in  turn 
are  assigned  appropriate  roles  based  on  their  qualifications  and  responsibilities.  To 
directly  represent  such  organizational  security  policies,  an  access  control  mechanism 
must  be  capable  of  supporting  roles.  Specifying  authorizations  on  roles  is  not  only 
convenient  but  reduces  the  complexity  of  administration  of  access  control  as  the  number 
of  roles  in  an  organization  are  significantly  smaller  than  the  number  of  users.  Role-based 
authorization  is  particularly  beneficial  in  workflow  environments  to  facilitate  dynamic  load 
balancing  when  several  individuals  can  perform  a  given  task.  As  a  matter  of  fact,  many 
commercial  applications  support  role-based  authorizations. 

Bertino,  Ferrari  and  Atluri  (BFA)  have  recently  presented  a  model  for  specifying  and 
enforcing  authorization  constraints  for  Workflow  Management  Systems  (WFMS)  in  [1], 
The  model  is  comprehensive  and  exhibits  strong  properties  such  as  (1)  a  language  to 
express  constraints,  (2)  formal  notions  of  constraint  consistency  and  (3)  algorithms  for 
role-task  and  user-task  assignments.  In  this  paper,  we  try  to  express  a  much  older 
model  called  Transaction  Control  Expressions  (TCEs)  in  the  BFA  model.  TCEs  were 
proposed  by  Sandhu  [5],  for  the  purpose  of  enforcing  dynamic  separation  of  duties 
constraints.  The  BFA  model  has  a  much  wider  scope  than  TCEs.  So  it  is  natural  to  ask 
whether  or  not  BFA  can  simulate  TCEs. 

In  spite,  of  the  generality  of  BFA  we  show  in  this  paper  that  the  BFA  model  cannot  fully 
express  TCEs.  In  particular,  the  notion  of  weighted  voting,  which  is  a  component  of 
TCEs,  cannot  be  expressed  in  the  BFA  model.  Our  paper  does  not  prove  this  formally, 
but  it  does  make  a  compelling  case  that  there  is  no  straightforward  way  of  expressing 
weighted  voting  in  BFA.  So  at  least  from  a  pragmatic  viewpoint  BFA  should  be  extended 
to  include  weighted  voting.  We  also  show  that  the  strong  properties  of  the  BFA  model 
are  still  preserved  in  the  extended-BFA  model,  which  incorporates  weighted  voting. 

The  rest  of  the  paper  is  organized  as  follows.  Sections  2  and  3  give  an  overview  of 
TCEs  and  the  BFA  model  respectively.  Section  4,  shows  how  most  aspects  of  TCEs  can 
be  easily  expressed  in  the  BFA  model,  except  for  weighted  voting.  Section  5  gives  the 
extended-BFA  model  and  section  6  shows  that  the  properties  of  the  BFA  model  are  still 
retained  in  exteqded-BFA  model.  Section  7  gives  the  conclusion. 


110 


2.  Transaction  Control  Expressions  (TCEs) 

In  this  section  we  describe  the  Transaction  Control  Expressions  as  proposed  by  Sandhu 
in  [5].  The  mechanism  is  very  natural  and  intuitive ,  being  close  in  spirit  and  letter  to 
controls  typically  encountered  in  paper-based  systems.  In  fact,  it  reflects  the  world  of 
forms  and  books  in  the  electronic  media  of  databases. 

Example  2.1 

Consider  a  situation  in  which  payment  in  the  form  of  a  check  is  prepared  and  issued  by 
the  following  sequence  of  events. 

1 .  A  clerk  prepares  the  check. 

2.  A  supervisor  approves  the  check. 

3.  A  clerk  issues  the  check. 

We  can  specify  some  separation  of  duties  constraints  so  that  the  users  cannot 
perpetrate  fraud  in  the  system.  One  such  constraint  can  be  explicitly  stated  as,  the  users 
performing  prepare,  approve  and  issue  transactions  should  all  be  different.  So  it  will  take 
collusion  of  two  clerks  and  a  supervisor  to  perpetrate  fraud.  This  is  called  dynamic 
separation  of  duties  since  a  clerk  can  perform  steps  1  and  3  on  different  vouchers,  but 
not  on  the  same  one.  Static  separation  of  duty  would  identify  two  kinds  of  clerk  roles, 
say  preparation_clerk  and  issue_clerk,  where  the  former  can  only  do  step  1  and  the 
latter  only  do  step  3.  Clearly  dynamic  separation  of  duties  is  more  efficient. 

The  above  example  is  expressed  in  TCEs  as  follows: 

prepare  •  clerk; 
approve  •  supervisor; 
issue  •  clerk; 

Each  term  of  a  transaction  control  expression  has  two  parts.  The  first  part  names  a 
transaction.  A  user  assigned  (explicitly  or  implicitly1)  to  the  role  specified  in  the  second 
part  can  execute  the  transaction. 

The  term  prepare  •  clerk;”specifies  that  the  prepare  transaction  can  be  executed  on  a 
check  object  only  by  a  clerk.  The  semi-colon  signifies  sequential  application  of  the  terms. 
That  is  a  supervisor  can  execute  the  approve  transaction  on  a  check  only  after  a  clerk 
has  successfully  executed  the  proceeding  prepare  transaction.  Finally,  separation  of 
duties  is  further  enforced  by  requiring  that  the  users  who  execute  different  transactions 
in  the  transaction  control  expression  all  be  distinct.  As  individual  transactions  are 
executed  the  expression  gets  incrementally  converted  to  a  history,  for  instance  as 
follows. 


prepare  •  Alice ; 

approvefsupervisor; 

issue«clqrk; 


prepare*A//ce; 

approve«Sob; 

issue*clerk; 


prepare*A//'ce; 
approve»Bof>; 
issu  e»Chris; 


<*) 


(b)  (c) 


1  Descriptions  of  rple  hierarchies  and  implicit  versus  explicit  role  assignments  are  presented  in 
[6], 
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The  identity  of  the  user  who  executes  each  transaction  is  recorded  to  enforce  the 
requirement  that  these  users  be  distinct.  So  if  Alice  attempts  to  issue  that  check  after 
point  (b)  in  this  sequence  the  system  rejects  the  attempt. 

A  transaction  control  expression  thus  contains  a  history  of  transactions  executed  on  the 
object  in  the  past  and  a  potential  history,  which  authorizes  transactions  that  can  be 
executed  in  the  future.  The  expression  begins  as  a  constraint  and  ends  as  a  complete 
history  of  the  object.  In  a  manual  system  identification  of  the  users  executing  each 
transaction  is  achieved  by  signatures.  In  automated  systems  user  identities  must  be 
recorded  with  guaranteed  correctness. 

Sometimes,  different  transactions  in  an  object  history  must  be  executed  by  the  same 
user. 

Example  2.2 

Consider  the  following  scenario,  a  project  leader  initiates  a  requisition,  a  purchase  order 
is  prepared  for  the  requisition  by  a  clerk  and  approved  by  a  purchasing  manager.  The 
purchase  order  then  needs  agreement  of  the  same  project  leader,  who  was  involved  in 
requisition.  Finally,  the  clerk  places  the  order. 

The  following  syntax  was  proposed  to  identify  steps  must  be  executed  by  the  same  user. 

requisition  •projectjeader  i  x; 
prepare_order  *clerk; 
approve_order  •purchasing_manager; 
agree  •  projectjeader  i  x; 
order*clerk; 

The  anchor  symbol  “^’’identifies  which  steps  must  be  executed  by  the  same  individual. 
The  ^’’following  it  is  a  token  for  relating  multiple  anchors.  For  instance,  in  the  above 
TCE  if  the  same  clerk  had  to  prepare  the  purchase  order  and  place  the  order  then  we 
can  use  the  anchor  symbol  “l”with  a  token  V”for  the  second  and  fifth  terms  in  the 
above  TCE. 

In  some  cases,  any  authorized  user  can  execute  a  transaction  in  an  object  history.  We 
modify  Example  2.1 .  Any  authorized  user  assigned  to  the  supervisor  role  can  perform 
step  2.  It  would  still  take  a  collusion  of  a  supervisor  and  a  clerk  to  perpetrate  fraud  in  the 
system.  If  the  role  hierarchy  is  such  that  the  supervisor  is  senior  to  the  clerk,  then  the 
supervisor  can  perform  prepare  and  approve  or  he/she  can  perform  approve  and  issue. 
But,  the  supervisor  cannot  perform  all  the  three  steps. 

The  following  syntax  identifies  steps,  which  can  be  performed  by  any  authorized  user. 

prepare  •  clerk; 
approve  •  supervisor  T; 
issue  •  clerk; 

Since  it  is  a  free  step  a  token  to  identify  multiple  anchors  is  not  needed.  (Free  steps  are 
an  extension  to  the  TCE  mechanism  proposed  in  [5].) 
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We  now  turn  the  focus  on  a  voting  scheme  scenario.  In  some  cases,  any  authorized 
user  can  execute  a  transaction  in  an  object  history.  We  modify  Example  2.1.  The  second 
step  now  requires  that  three  different  supervisor  approve  the  check.  The  following  syntax 
is  used  to  express  the  voting  scheme. 

prepare  •  clerk; 

3:  approve  •  supervisor^; 
issue  •  clerk; 

The  colon  is  a  voting  constraint  specifying  3  votes  from  3  different  supervisors.  This 
notion  is  further  extended  to  include  weights  of  different  role  as  follows: 

prepare  •  clerk; 

3:  approve  •  manager  =  2,  supervisor  =  1 ; 
issue  •  clerk; 

In  this  case,  approve  transactions  with  sufficient  votes  are  required  before  proceeding  to 
the  next  term.  The  number  of  votes  required  is  interpreted  as  a  lower  bound.  The 
moment  3  or  more  votes  are  obtained  the  next  step  is  enabled. 


3.  The  BFA  model  for  workflow  authorization 

In  this  section  we  describe  the  workflow  authorization  model  proposed  by  Bertino, 

Ferrari  and  Atluri  in  [1],  which  for  convenience  we  call  the  BFA  model.  The  BFA  model 
gives  a  language  for  defining  constraints  on  role  assignment  and  user  assignment  to 
tasks  in  a  workflow.  By  using  this  language,  we  can  express  conditions  constraining  the 
users  or  roles  that  can  execute  a  task.  The  constraint  language  supports,  among  other 
functions,  both  static  and  dynamic  separation  of  duties.  Because,  the  number  of  tasks 
and  constraints  can  be  very  large,  the  BFA  model  provides  formal  notions  of  constraint 
consistency  and  has  algorithms  for  consistency  checking.  Constraints  are  formally 
expressed  as  clauses  in  a  logic  program.  The  BFA  model  also  gives  algorithms  for 
planning  role  and  user  assignments  to  various  tasks.  The  goal  of  these  role-task  and 
user-task  planners  is  to  generate  a  set  of  possible  assignments,  so  that  all  constraints 
stated  as  part  of  authorization  specification  are  satisfied.  The  planner  is  activated  before 
the  workflow  execution  starts  to  perform  an  initial  plan.  This  plan  can  be  dynamically 
modified  during  the  workflow  execution,  to  take  into  account  specific  situations,  such  as 
the  unsuccessful  execution  (abort)  of  a  task. 

In  the  BFA  model,  as  in  most  WFMSs,  there  is  an  assumption  that  a  workflow  consists 
several  tasks  to  be  executed  sequentially.  A  task  can  be  executed  several  times  within 
the  same  workflow.  Such  an  occurrence  of  a  given  task  T  is  called  an  activation  of  T.  All 
activations  of  a  task  must  be  complete  before  the  next  task  in  the  workflow  can  begin. 
Each  task  is  associated  with  one  or  more  roles.  These  roles  are  the  only  ones 
authorized  to  execute  the  task.  In  the  remainder  of  this  section  U,  R,  T  respectively 
denote  the  set  of  users,  the  set  of  roles  and  the  set  of  tasks  in  a  given  workflow. 

In  the  BFA  model  the  workflow  role  specification  is  formally  defined  as  follows. 

Definition  3.1  (BFA  Workflow  Role  Specification)  A  workflow  role  specification  Wis  a 
list  of  task  role  specifications  [TRS,,  TRS2 . TR§],  where  each  TRSjis  a  3-tuple  (Tj. 
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(RSj  >j),  actj  where  Tj€  T  is  a  task,  RSie  R  is  the  set  of  roles  authorized  to  execute  T  j , 

>i,  is  a  local  role  order  relationship,  and  ache  N  is  the  number  of  possible  activations  of 
task  Ti.  The  workflow  tasks  are  sequentially  executed  according  to  the  order  in  which 
they  appear  in  the  workflow  role  specification. 

In  order  to  provide  a  semantic  foundation  for  the  BFA  model  and  to  formally  prove 
consistency,  the  constraints  are  represented  as  clauses  in  a  normal  logic  program.  The 
clauses  in  a  logic  program  can  contain  negative  literals  in  their  body. 

Definition  3.2  (Constraint  Specification  Language) 

The  constraint  specification  language  was  specified  by  defining  the  set  of  constants, 
variables  and  predicate  symbols. 

In  the  following  C  denotes  a  set  of  constraint  identifiers. 

-  Constant  Symbols:  Every  member  of  the  set  of  users  (U),  set  of  roles  (R),  set  of 
transactions  (7),  set  of  constraints  (C),  and  the  set  of  natural  numbers  (N). 

Variable  Symbols:  There  are  five  sets  of  variable  symbols  ranging  over  the  sets  U,  R, 
T,  C  and  N  denoted  as  Vu,  Vr,  Vt,  Vc  and  Vn  respectively.  The  user  terms  are 
denoted  with  UT  the  set  Vu  u  U.  Similarly,  RT,  TT,  CT,  NT  denote  the  sets  Vr  u  R, 
VtuT.VcuC  and  Vn  u N. 

Predicate  Symbols:  The  set  of  predicate  symbols  consists  of  five  sets: 

1 .  A  set  of  specification  predicates  SP  expressing  information  concerning  the 
specification  of  a  workflow. 

2.  A  set  of  execution  predicates  EP  capturing  the  effect  of  TCE  execution 

3.  A  set  of  planning  predicates  PP  expressing  the  restrictions  imposed  by  the 
constraints  on  the  set  of  users  that  can  execute  a  task. 

4.  A  set  of  comparison  predicates  CP  capturing  Comparison  operators 

5.  A  set  of  aggregate  predicates  AP  capturing  the  aggregate  operators 


Appendix  A  has  the  table  of  all  the  predicates  used  in  this  paper,  a  complete  list  of  all 
the  predicates  and  their  descriptions  is  given  in  [1]. 

A  rule  is  an  expression  of  the  form: 

H  <-  A1 , . An,  not  B1 . not  Bm,  n,m>=  0 

Where  H,  A1 . An  and  B1 . Bm  are  atoms  and  not  denotes  negation  by  failure.  H  is 

the  head  of  the  rule  and  whereas  A1, . An,  not  B1 . not  Bm  is  the  rule  body.  Rules 

can  be  expressed  in  the  constraint  specification  language  can  be  classified  into  a  set  of 
categories  according  to  the  predicate  symbols  they  contain.  Namely,  explicit  rules, 
assignment  rules,  static  checking  rules  and  integrity  rules. 

Appendix  B  has  the  table  of  all  the  rules  mentioned  above  and  their  descriptions.  The 
definitions  of  these  rules  and  their  description  are  given  in  [1]. 

Definition  3.3  (Constraint-Base)  Let  W  be  a  workflow.  The  Constraint-Base  associated 
with  W  (written  CB  (W))  consists  of  a  set  of  explicit,  assignment  and  integrity  rules. 
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Intuitively,  a  CB  is  consistent  if  and  only  if  the  constraints  it  encodes  are  satisfiable.  The 
consistency  of  a  CB  is  determined  by  computing  and  analyzing  its  model.  Details  on  CB 
consistency,  consistency  analysis  and  role-task  /  user-task  assignment  algorithms  are 
presented  in  [1]. 

4.  Expressing  TCEs  in  BFA 

In  this  section  we  show  how  the  separation  of  duties  constraints  of  TCEs  can  be 
expressed  in  the  BFA  model.  We  illustrate  this  by  expressing  all  the  TCEs  mentioned  in 
section  2  in  BFA.  In  this  section  we  also  argue  that  the  weighted  voting  scenario  which 
was  expressed  in  section  2  cannot  be  expressed  in  BFA.  Although,  this  is  not  formally 
proved,  we  make  a  compelling  case  that  there  is  no  straightforward  way  of  expressing 
weighted  voting  in  BFA.  So  at  least  from  a  pragmatic  viewpoint  BFA  should  be  extended 
to  include  weighted  voting. 

Basic  TCE 

Consider  the  following  TCE  presented  in  section  2  and  the  global  role  hierarchy  in 
Figurel : 

prepare  •  clerk; 
approve  •  supervisor; 
issue  •  clerk; 


The  separation  of  duties  constraints  can  be  enumerated  as  follows: 

C,:  A  user  cannot  execute  approve,  if  he/she  had  successfully  executed  prepare. 

C2:  A  user  cannot  execute  issue,  if  he/she  had  successfully  executed  prepare  or 

approve. 


1  supervisor 
clerk 

Figure  1 :  Role  Hierarchy 


These  can  be  expressed  in  BFA  as  follows: 

Workflow  W=  [  (prepare, ({clerk,  supervisor},  {}),  1), 
(approve, ({supervisor},  0),  1). 

(issue, ({clerk,  supervisor},  {}),  1)  ] 


Constraint  Base  CB  (W): 

Rij.  cannot_dou(U,  approve)  <- executeu(U,  prepare, 1); 
R2i1:  cannot_dou(U,  issue)  <-  executeu(U,  approve, 1); 
R2,2-  cannot_dou(U,  issue)  <-  executeu(U,  prepare, 1); 
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TCE  with  Anchors 

Consider  the  following  TCE  presented  in  section  2  and  the  global  role  hierarchy  in 
Figure2: 

requisition  •projectjeader  i  x; 
prepare_order  •clerk; 
approve_order  •purchasing_manager; 
agree  •  projectjeader  i  x; 
order«clerk; 


purchasing. 

manager 

clerk 


project,  leader 


Figure  2:  Role  Hierarchy 


The  separation  of  duties  constraints  can  be  enumerated  as  follows: 

C,:  A  user  cannot  execute  prepare.order,  if  he/she  had  successfully  executed 

requisition. 

C2:  A  user  cannot  execute  approve.order,  if  he/she  had  successfully  executed 

requisition  or  prepare.order. 

C3:  A  user  executing  agree  must  be  the  same  user  who  had  successfully  executed 

requisition. 

C4:  A  user  cannot  execute  order,  if  he/she  had  successfully  executed  requisition, 

prepare.order,  approve.order  or  agree. 

These  can  be  expressed  in  BFA  as  follows: 

Workflow  W=  [  (requisition, ({projectjeader},  {}),  1). 

(prepare.order, ({clerk,  purchasing_manager},  0),  1). 
(approve.order, ({purchasing_manager},  {}),  1), 

(agree, ({projectjeader},  {}),  1), 

(order, ({clerk,  purchasing_manager},  {}),  1)  ] 

Constraint  Base  CB  (W): 

R1fi :  cannot_dou(U,  prepare.order)  4-  executeu(U,  requisition^); 

R2,i:  cannot_dou(U,  approve.order)  <—  executeu(U,  prepare.order, 1); 
F?2,2.  cannot_dou(U,  approve.order)  4-  executeu(U,  requisition, 1); 
f?3iJ;must_executeu(U,  agree)  4-  executeu(U,  requisition, 1); 
R*,}.cannot_dou(U,  order)  <-  executeu(U,  agree, 1); 

/?4,2.  cannot_dou(U,  order)  <-  executeu(U,  approve.order, 1); 
R*,3;Cannot_dOu(U,  order)  4-  executeu(U,  prepare.order, 1); 
R4,4;cannot_dou(U,  order)  4-  executeu(U,  requsition.l); 
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TCE  with  Weighted  Voting 

Consider  the  following  TCE  presented  in  section  2  and  the  role  hierarchy  in  Figure  3. 
In  this,  TCE  the  notion  of  voting  was  further  extended  to  include  different  weights  to 
different  roles  as  follows: 

prepare  •  clerk; 

3:  approve  •  manager  =  2,  supervisor  =  1 ; 
issue  •  clerk; 


manager 


supervisor 


clerk 


Figure  3:  Role  Hierarchy 


In  this  case,  the  manager  has  a  weight  of  2  and  the  supervisor  has  a  weight  of  1  for  the 
approve  transactions.  The  number  of  votes  required  for  approve  transaction  to  be 
successful  is  3.  As  soon  as  3  or  more  votes  are  obtained  the  next  step  is  enabled. 

We  know  that  the  BFA  model  does  not  support  assigning  weights  to  roles  (by  definition 
3.1).  So  we  enumerate  the  various  possible  role  assignments  to  approve  and  try  to 
capture  all  the  possible  assignments  as  constraints  in  CB  (W).  Table  1  below,  gives  the 
various  possible  assignments  for  approve. 


Role  Assignmenl 

for 

Possibility  No. 

Activation  1 

Activation  2 

Activation  3 

Total 

Activations 

Votes 

Registered 

1 

Supervisor 

supervisor 

Supervisor 

3 

3 

2 

Supervisor 

supervisor 

Manager 

3 

4 

3 

Supervisor 

manager 

- 

2 

3 

4 

Manger 

supervisor 

- 

2 

3 

5 

Manger 

manager 

- 

2 

4 

Table  1:  Possible  role  assignments  for  approve 

Recall  that,  a  CB  for  a  workflow  consists  of  a  set  of  explicit,  assignment  and  integrity 
rules  (definition3.3).  We  now  try  to  express  all  the  possible  role  assignments  for  approve 
with  these  rules. 

Expressing  the  possible  role  assignments  as  constraints  using  Explicit  rules: 
Explicit  rules  contain  an  execution  or  a  specification  atom  in  the  head  and  an  empty 
body.  The  various  possibilities  of  table  1  cannot  be  expressed  using  execute  ,  as  each 
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TCE  with  Free  Steps 

Consider  the  following  TCE  presented  in  section  2  and  the  global  role  hierarchy  in 
Figurel : 


prepare  •  clerk; 
approve  •  supervisor  t; 
submit  •  clerk; 

The  separation  of  duties  constraints  can  be  enumerated  as  follows: 

Ci'.  A  user  cannot  execute  issue,  if  he/she  had  successfully  executed  prepare  or 
approve. 

These  can  be  expressed  in  BFA  as  follows; 

Workflow  W=  [  (prepare, ({clerk,  supervisor},  {}).  1). 

(approve, ({supervisor},  0).  1). 

(issue, ({clerk,  supervisor},  {}),  1)  ] 

Constraint  Base  CB  (W}: 

R,,t..cannot_dou(U,  issue)  4-  executeu(U,  approve, 1); 
f?7,2.-cannot_dou(U,  issue)  4-  executeu(U,  prepare, 1); 

TCE  with  Simple  Voting 

Consider  the  following  TCE  presented  in  section  2  and  the  global  role  hierarchy  in 
Figurel.  In  this  TCE,  equal  weights  are  assigned  to  the  role  supervisor. 

prepare  •  clerk; 

3:  approve  •  supervisor^ ; 
issue  •  clerk; 

The  separation  of  duties  constraints  can  be  enumerated  as  follows: 

Ci:  A  user  cannot  execute  approve,  if  he/she  had  successfully  e  xecuted  prepare. 

C2:  A  user  cannot  execute  approve,  more  than  once.  (Three  different  users  have  to 

execute  approve). 

C3:  A  user  cannot  execute  issue,  if  he/she  had  successfully  executed  prepare  or 

approve. 

These  can  be  expressed  in  BFA  as  follows: 

Workflow  W=  [  (prepare, ({clerk,  supervisor},  0).  1). 

(approve, ({supervisor},  {}),  3), 

(issue, ({clerk,  supervisor},  {}),  1)  ] 

Constraint  Base  CB(W) : 

f?7,J;cannot_dou(U,  approve)  4-  executeu(U,  prepare, 1); 
f?2,f;Cannot_dou(U,  approve)  4-  executeu(U,  approve, 1); 

R2.2.  cannot_dou(U,  approve)  4-  executeu(U,  approve, 2); 

R3i1. cannot_dou(U,  issue)  4-  executeu(U,  approve, 1); 

R3,2.  cannot_dou(U,  issue)  4-  executeu(U,  approve, 2); 

R3,3.  cannot_dou(U,  issue)  4-  executeu(U,  approve, 3); 
R3,4;Cannot_dou(U,  issue)  4-  executeu(U,  prepare, 1); 
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activation  of  approve  can  be  executed  by  the  supervisor  or  the  manager.  We  cannot  use 
the  constraints  expressed  as 
executer  (supervisor,  approve,  1)  <- 
or 

executer  (manager,  approve,  1 )  <- 

to  capture  the  role  assignments  of  table  1  since,  activation  1  of  approve  can  be  executed 
by  the  supervisor  or  manager.  So  we  cannot  express  the  possible  role  assignments  for 
approve  in  table  1  using  explicit  rules. 

Expressing  the  possible  role  assignments  as  constraints  using  Assignment  rules: 
Assignment  rules  contain  a  must_executeUl  must_executer,  cannot_dou  or  cannot_dor 
atom  in  the  head  and  specification  atoms,  execution  atoms,  comparison  literals,  or 
aggregate  atoms  in  the  body.  The  must_execute  r  or  cannot_dor  atoms  can  be  used  in 
the  head  of  the  rules  to  express  the  role  assignment  constraints.  As  each  activation  of 
approve  can  be  assigned  to  a  manager  or  a  supervisor  we  cannot  use  the  constraints 
expressed  as 

cannot_dor(supervisor,  approve)  <-  executer(supervisor,  approve,  1), 

executer(supervisor,  approve,  2) ; 
or 

must_executer(supervisor,  approve)  <—  executef(supervisor,  approve,  1), 

executer(supervisor,  approve,  2) ; 

to  capture  the  role  assignments  of  table  1.  This  is  because,  activation  3  of  approve  can 
be  executed  by  the  supervisor  or  manager,  even  if  the  activation  1  and  activation  2  are 
successfully  executed  by  the  supervisor  role.  So  we  cannot  express  the  possible  role 
assignments  for  approve  in  table  1  using  assignment  rules. 

Expressing  the  possible  role  assignments  as  constraints  using  Integrity  rules: 
Integrity  rules  contain  a  panic  atom  in  the  head  and  specification  atoms,  execution 
atoms,  comparison  literals,  or  aggregate  atoms  in  the  body.  The  same  argument 
presented  for  assignment  rules  holds  here.  So  we  can  say,  that  we  cannot  express  the 
possible  role  assignments  for  approve  in  table  1  using  integrity  rules. 

We  have  already  argued  above,  that  the  possible  role  assignments  for  weighted  voting 
scenario  cannot  be  expressed  by  the  explicit,  assignment  and  integrity  rules  of  the  CB. 
Also,  the  definition  for  a  Workflow  (definition  3.1)  does  not  support  assigning  weights  to 
each  role.  So,  we  conjecture  there  are  no  straightforward  ways  to  express  weighted 
voting  schemes  in  BFA. 

Conjecture  1 :  There  are  no  straightforward  ways  to  express  weighted  voting  in  BFA. 

A  stronger  conjecture  would  assert  that  there  are  no  ways,  straightforward  or 
convoluted,  to  express  weighted  voting  in  BFA.  A  formal  proof  of  this  stronger 
conjecture  would  be  of  theoretical  interest  but  is  outside  the  scope  of  this  paper. 

From  a  practical  perspective  it  is  quite  simple  to  add  the  weighted  voting  feature  to  BFA. 
Weighted  voting  has  been  previously  proposed  in  the  literature  and  is  intuitively  a  simple 
and  natural  concept.  This  is  accomplished  in  the  next  section. 


119 


5.  The  Extended-BFA  Model 

In  this  section  we  describe  the  extended-BFA  model,  to  accommodate  the  scenarios  of 
weighted  voting.  We  modify  the  definition  of  the  BFA  workflow-role  specification 
(Definition  3.1)  as  follows. 

Definition  5.1  (Extended-BFA  Workflow  Role  Specification)  A  workflow  role 
specification  Wis  a  list  where  each  element  in  the  list  is  either  a  task-role  specification  or 

a  vote-role  specification  [TRSi/  VRSi,  TRS2/  VRS2 . TR3VRSn], 

where  each 

TRSi  is  a  3-tuple  (Tj,  (RSj  >i),  act,)  where  Te  T  is  a  task,  RSj  e  R  is  the  set  of  roles 
authorized  to  execute  Tj,  >i,  is  a  local  role  order  relationship,  and  ache  N  is  the  number 
of  possible  activations  of  task  T  j. 
and  each, 

VRSi  is  a  4-tuple  (Tj,  (RSf  >j) , VotesRequired,  RoleWeight)  where  Tj  e  T  is  a  task,  RSj  e  R 
is  the  set  of  roles  authorized  to  execute  T  i. ,  >j.,  is  a  local  role  order  relationship,  and 
VotesRequired  e  N  is  the  number  of  votes  required  to  make  of  task  T  i  and  RoleWeight  is 
a  function  that  maps  each  role  in  the  set  RS  i  to  a  weight  e  N  for  a  given  Tj. 

RoleWeight:  RSi.  ->  N 

The  workflow  tasks  are  sequentially  executed  according  to  the  order  in  which  they 
appear  in  the  workflow  role  specification. 

We  propose  two  possible  solutions  for  expressing  the  weighted  voting  constraints  in 
extended-BFA  model. 

Solution  1  forexpressing  the  weighted  voting  constraint  in  extended-BFA: 

The  weighted  voting  constraint  could  be  expressed  as  in  terms  of  the  number  of 
successful  activations  of  the  task  approve  as  follows: 


cannot_dou(U,  issue)  <—  count(success(approve,  k),  executer(Ri,  approve,  k ), 

Ri=  manager,  n^, 

count(success(approve,  k),  executer(Rj,  approve,  k ), 

Rj  =  supervisor,  n2), 

(2*  ni  +  n2)  <  3; 

Here,  we  count  the  number  of  successful  executions  of  the  task  approve  by  the  role 
manager  (returned  as  m),  the  number  of  successful  executions  of  the  task  approve  by 
the  role  supervisor  (returned  as  n2)  and  compute  the  votes  registered  as  (2*  n  i  +  n2). 
Since  the  manager  has  a  weight  of  2  and  the  supervisor  has  a  weight  of  1  .If  the  votes 
registered  are  less  than  3,  then  users  cannot  perform  the  task  issue. 

This  solution  is  inefficient  if  there  are  a  number  of  different  roles  assigned  different 
weights  for  the  task.  Therefore,  we  propose  a  second  solution  to  express  weighted 
voting  efficiently  in  the  extended-BFA  model. 

Solution  2  for  expressing  the  weighted  voting  constraint  in  extended-BFA: 

We  add  the  following  weighted  voting  predicates  and  the  weighted  voting  rule  to 
efficiently  express  weighted  voting  in  the  extended  BFA  model. 
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Predicate 

Arity 

Arguments’ 

Type 

Meaning 

role_weight 

3 

RT,  TT,  NT 

role_weight(Rj,  Tj,  n)  gets  the  weight  of  the  role  R 
assigned  to  the  Task  Tj  and  returns  this  value  as  n. 

votes_required 

2 

TT,  NT 

votes_required(Ti,  n)  gets  the  minimum  number  of 
votes  required  for  the  task  Tj  to  be  successful  and 
returns  this  value  as  n. 

count_votes 

2 

TT,  NT 

count_votes(Ti,  n)  computes  the  following: 

for  each  Re  RSj. 
begin 
sum:=0 

count(success(Tj,  k),  executer(R,  Tj„  k),  n^ 
role_weight(R,  Th  n2) 
sum  :=sum  +  (ni  *  n2) 
end; 

and  returns  the  value  of  sum  as  n. 

Table  2:  Weighted  Voting  predicates 


Definition  5.2  (Extended-BFA  Constraint  Specification  Language) 

The  extended-BFA  Constraint  Specification  Language  is  unchanged  from  definition  3.2 
except  for  the  addition  of  the  weighted  voting  predicates  described  in  table  2. 


Rule 

Head 

Body 

Weighted  Voting 

cannot_dou 

conjunction  of  comparison  literals  and 
weighted  voting  predicates 

Table  3:  Weighted  Voting  rule 


Definition  5.3  (Constraint-Base)  The  extended-BFA  Constraint-Base  is  unchanged 
from  definition  3.3  except  for  the  addition  of  the  weighted  voting  rule  described  in  table  3. 

With  the  help  of  above  weighted  voting  predicates  and  weighted  voting  rule  we  can  now 
express  a  TCE  with  a  voting  scheme  in  Extended-BFA.  Consider  the  TCE  presented  in 
section  2  and  the  global  role  hierarchy  in  Figure  3. 

prepare  •  clerk; 

3:  approve  •  manager  =  2,  supervisor  =  1 ; 
issue  •  clerk; 

The  separation  of  duties  constraints  can  be  enumerated  as  follows: 

Ci:  A  user  cannot  execute  approve,  if  he/she  had  successfully  executed  prepare. 

C2:  A  user  cannot  execute  approve,  more  than  once.  (Three  different  users  have  to 

execute  approve). 

C3:  A  user  cannot  execute  issue  until  approve  transaction  registers  the  required 

number  of  votes. 

Ci.  A  user  cannot  execute  issue,  if  he/she  had  successfully  executed  prepare  or 
approve. 
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These  can  be  expressed  in  Extended-BFA  as  follows: 

Workflow  W  =  [  (prepare, ({clerk,  supervisor,  manager},  0).  1). 

(approve, ({supervisor,  manger),  0).  3,{(supervisor,1), (manager, 2)}), 
(issue, ({clerk,  supervisor,  manager},  0).  1)  ] 

Constraint  Base  CB(W) : 

cannot_dou(U,  approve)  <-  execute U(U,  prepare, 1); 

/?2>j;cannot_dou(U,  approve)  <-  executeu(U,  approve,  1); 

R2,2.  cannot_dOu(U,  approve)  <-  executeu(U,  approve,  2); 

R3,7;cannot_dou(U,  issue)  <-  count_votes(T|,  ni),  votes_required(Ti,  n2),  nn  <  n2; 
R4,?;Cannot_dou(U,  issue)  <-  executeu(U,  approve,  1); 

R*>2;cannot_dou(U,  issue)  <-  executeu(U,  approve,  2); 

R4>3;cannot_dou(U,  issue)  <-  executeu(U,  approve,  3); 

/?4,4.  cannot_dou(U,  issue)  <-  executeu(U,  prepare, 1); 

The  rule  R4,3  will  only  be  effective  if  the  approve  task  had  three  activations  (the 
maximum  number  of  possible  activations).  If  the  number  of  activations  for  the  approve 
task  was  less  then  three,  then  this  rule  will  be  ineffective  as  executeu(U,  approve,  3)  will 
always  be  false. 

6.  Properties  of  the  Extended  BFA  model 

We  now  focus  the  attention  on  showing  that  the  properties  of  the  BFA  model  are  still 
preserved  in  the  extended-BFA  model. 

The  properties  of  the  BFA  model  as  mentioned  earlier  are: 

(1)  a  language  to  express  constraints 

(2)  formal  notions  of  constraint  consistency  and 

(3)  algorithms  for  role-task  and  user-task  assignments. 

In  the  extended-BFA  model,  we  have  not  changed  the  language  to  express  constraints, 
so  property  (1)  is  preserved.  The  formal  proof  for  the  following  proposition  as  presented 
in  [1]  still  holds. 

Proposition  6.1  Any  CB  is  a  stratified  normal  program.  Hence ,  it  has  a  unique  stable 
model. 

Since  we  have  not  changed  the  definitions  of  explicit,  assignment  and  integrity  rules. 

The  formal  proof  presented  for  this  proposition  in  [1]  still  holds  for  these  rules.  We  now 
extend  the  argument  presented  in  [1]  to  include  the  weighted  voting  rule. 

A  program  P  is  stratified  if  its  extended  dependency  graph  does  not  contain  any  cycle 
involving  an  edge  labeled  with  hot”[10],  where  the  extended  dependency  graph  of  a 
program  P  is  a  graph  whose  nodes  are  the  predicates  that  appear  in  the  heads  of  the 
rules  of  P.  Given  two  nodes  pi  and  p2  there  is  a  direct  edge  from  pi  to  p2  if  and  only  if 
predicate  p2  occurs  positively  or  negatively  in  the  body  of  a  rule  whose  head  predicate  is 
pi.  The  edge  (pi,  p2)  is  marked  with  a  hofsign  if  and  only  if  there  exists  at  least  one 
rule  r  with  head  predicate  pi  such  that  p2  occurs  negatively  in  the  body  of  r.  By 
Definition  5.3,  the  CB  associated  with  a  given  workflow  consist  of  a  set  of  explicit, 
assignment,  integrity  and  weighted  voting  rules.  The  explicit,  assignment  and  integrity 
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rules  cannot  form  a  cycle  in  the  extended  dependency  graph  [1].  By  definition  the 
weighted  voting  rule  has  a  planning  predicate  ( cannot_dou)  as  head  and  a  conjunction  of 
weighted  voting  predicates  and  comparison  literals  as  body.  Since,  the  predicates  that 
appear  in  the  head  are  disjoint  from  the  predicates  that  can  appear  in  the  body,  they 
cannot  form  any  cycle  in  the  extended  dependency  graph.  Hence,  the  extended 
dependency  graph  associated  with  a  CB  does  not  contain  any  cycle.  Thus,  the  CB  is 
stratified. 

The  static  analysis  algorithm  and  the  pruning  algorithm  need  some  modifications  to 
accommodate  the  VRSiS  in  addition  to  the  TRSjS.  These  modifications  are  simple  to 
make  in  order  to  preserve  property  (2). 

The  role-task  and  user-task  assignment  algorithms  also  need  modification,  to 
accommodate  the  VRSiS.  Instead,  of  looping  through  the  number  of  activations  in  each 
TRSi.  they  have  to  also  consider,  that  each  element  of  the  workflow  can  be  a  VRSj.  In 
case,  an  element  is  a  VRSi.  they  need  to  keep  track  of  the  number  of  votes  required 
after  each  assignment  and  the  weights  assigned  to  each  role.  With  these  modifications, 
property  (3)  of  the  BFA  model  can  also  be  preserved. 

Thus,  we  argue  that  with  some  modifications  to  the  static  analysis  algorithm,  pruning 
algorithm,  role-task  assignment  algorithm  and  user-task  assignment  algorithm  the 
extended-BFA  model  preserves  the  strong  properties  of  the  BFA  model. 

7.  Conclusion 

In  this  paper,  we  have  shown  that  the  BFA  model  cannot  be  used  to  express  the 
weighted  voting  scenario.  We  have  extended  the  BFA  model  so  that  this  feature  can  be 
accommodated  in  the  BFA  model.  We  have  also  argued  that  the  extended-BFA  model 
does  preserve  all  the  properties  of  the  BFA  model.  It  should  also  be  noted  that  the 
constraint  specification  language  of  BFA  is  not  intended  for  end-users  to  express 
constraints,  it  is  rather  used  internally  by  the  system  to  analyze  and  enforce  constraints. 
The  TCEs  on  the  other  hand  are  very  natural  and  intuitive,  so  we  can  use  TCEs  as  a 
language  in  which  users  can  specify  their  separation  of  duties  constraints.  The 
constraints  in  TCEs  can  be  translated  to  BFA.  This  reduction  to  extended  BFA  also 
provides  a  formal  semantics,  which  has  so  far  not  been  given. 

Future  directions  of  our  research  could  involve  developing  an  automated  system  to 
translate  TCEs  into  the  BFA  model ,  this  could  be  helpful  as  the  BFA  model  has  formal 
semantics  for  expressing  constraints  at  the  system  level.  The  BFA  model  and  the  TCEs 
follow  a  strict  sequence  of  execution.  We  would  also  like  to  introduce  some  parallelisms 
in  the  task  execution. 
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Appendix  A  (Predicates  used  in  this  paper) 


Predicate 

Arity 

Arguments’  Type 

Meaning 

executeu 

3 

UT,  TT,  NT 

If  executeu  (Ui,  Tjf  k)  is  true  is  true,  then  the 
k-th  activation  of  task  Tj  is  executed  by  user 
Ui. 

executer 

3 

RT,  TT,  NT 

If  execute,,  (R,  Tj,  k)  is  true  is  true,  then  the 
k-th  activation  of  task  T  is  executed  by  role 
Ri. 

success 

2 

TT,  NT 

success(Tj,  K)  is  true  if  the  k-th  activation  of 
task  Tj  within  a  workflow  successfully 
executes 

must_executeu 

2 

UT,  TT 

If  must_executeu(Ui,Tj)  is  true  then  task  Tj 
must  be  executed  by  user  Ui. 

must_executer 

2 

RT,  TT 

If  must_executer(Ri,Tj)  is  true  then  task  Tj 
must  be  executed  by  role  Rj. 

cannot_dou 

2 

UT.TT 

If  cannot_dou(Uj,  Tj)  is  true  then  the  task  Tj 
cannot  be  assigned  to  user  Uj. 

cannot_dor 

2 

RT.TT 

If  cannot_dor(Rit  Tj)  is  true  then  the  task  Tj 
cannot  be  assigned  to  role  Rj. 

Appendix  B  (Constraint  Specification  Language  Rules) 


Rule 

Head 

Body 

explicit 

execution  or  specification 
atom 

empty 

assignment 

must_executeu, 
must_executer, 
cannot_do„  or  cannot_dor 
atom 

specification,  execution,  or  comparison 
literals,  or  aggregate  atoms 

static  checking 

statically_checked  atom 

specification,  comparison  literals,  or 
aggregate  atoms.  Each  literal  in  an 
aggregate  atom  is  a  specification  or  a 
comparison  literal 

integrity 

panic  atom 

specification,  execution,  or  comparison 
literals,  or  aggregate  atoms 

static 

planning  or  specification 
atom 

specification,  comparison  literals,  or 
aggregate  atoms.  Each  literal  in  an 
aggregate  atom  is  a  specification  or  a 
comparison  literal 

dynamic 

planning  execution  or 
specification  atom 

specification,  execution,  comparison 
literals,  or  aggregate  atoms.  At  least  a 
literal  in  the  rule  must  be  an  execution 
literal. 
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Abstract 

Current  DoD  information  systems  need  to  support  many  different  missions  through  cooperation  with 
different  organizations  and  allies.  In  today’s  fast  paced  and  dynamic  environment,  it  is  almost  impossible  to 
design  and  implement  a  different  information  system  for  each  mission.  Therefore,  DoD  needs  MLS 
workflow  management  systems  (WFMS)  to  enable  globally  distributed  users  and  existing  applications  to 
cooperate  across  classification  domains  to  achieve  mission  critical  goals.  An  MLS  WFMS  that  allows  users 
to  program  multilevel  mission  logic,  securely  coordinate  widely  distributed  tasks,  and  monitor  the  progress 
of  the  workflow  across  classification  domains  is  required.  In  this  paper,  we  present  requirements  for  MLS 
workflow  and  a  strategy  for  implementing  it,  especially  the  method  for  decomposing  an  MLS  workflow 
into  multiple  single-level  workflows 


1.  Introduction 

The  streamlining  of  today’s  business  processes  has  brought  about  significant  increases  in  productivity  and 
the  ability  for  US  companies  to  compete  in  the  global  market  place.  These  re-engineering  activities  have  as 
their  basis  an  even  greater  reliance  on  information  technology  and  automation.  As  a  result,  software 
developers  have  been  challenged  to  streamline  the  software  development  process  and  to  produce  software 
that  can  be  reused,  that  separates  concerns,  that  supports  autonomy  and  heterogeneity  in  a  distributed 
computing  environment,  that  allows  extensibility,  etc.  The  information  technology  (IT)  community  has 
developed  distributed  object  computing  standards,  like  CORBA  and  DCOM,  that  provide  a  basic  level  of 
interoperability  among  distributed  applications.  The  next  step  is  to  build  application  specific  software 
architectures  that  encode  business  logic  for  coordinating  widely  distributed  manual  and  automated  tasks  in 
achieving  enterprise  level  objectives.  To  assist  business  process  modeling,  vendors  have  developed  several 
automated  tools  that  help  manage  dependence  among  activities  and  users.  A  WFMS  makes  these  tools 
available  to  users  and  allows  them  to  monitor  the  business  processes.  This  technology  manages  activities 
within  a  distributed  computing  environment  comprising  of  loosely  coupled,  heterogeneous,  autonomous, 
new  (and  legacy)  components  which  may  include  transactional  systems  (i.e.,  DBMS).  It  provides  a 
capability  for  defining  the: 

♦  Business  logic, 

♦  Tasks  that  make  up  business  processes,  and 

♦  Control  flow  and  data  dependence  among  those  tasks. 

The  potential  benefits  of  this  technology  are  enormous  because  of  its  broad  reach  to  manage  business 
process  productivity.  Industry  is  beginning  to  turn  to  workflow  technology  in  order  to  minimize  its 
manpower  needs,  optimize  IT  investment,  achieve  good  performance,  use  legacy  systems,  gain  flexibility 
for  supporting  evolving  business  goals,  as  well  as  to  capitalize  on  advanced  technology.  However, 
commercial  WFMS  do  not  support  distributed  mission  critical  applications.  They  do  not  ensure  mission 
critical  properties,  such  as  recoverability  nor  do  they  enforce  access  control  policies,  and  certainly  not 
multilevel  secure  (MLS)  access  control  policies.  Even  though  there  is  a  great  need  for  this  technology  in 
DoD,  DoD  cannot  rely  on  commercial  WFMS  to  protect  national  security  information  and  perform  mission 
critical  business  processes. 
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The  constant  aspect  of  the  military  challenge  is  change.  The  challenge  is  to  respond  to  new  threats  in 
completely  different  environments.  For  example,  today’s  military  supports  disaster  relief,  drug  interdiction, 
peace-keeping  missions  in  worldwide  regional  skirmishes,  treaty  enforcement,  as  well  as  the  traditional  role 
of  national  defense  against  aggression  and  weapons  of  mass  destruction.  At  no  other  time  in  the  nation’s 
history  has  the  military  relied  so  heavily  on  IT  systems  for  all  of  its  operations,  including  command  and 
control,  logistics,  surveillance  and  reconnaissance,  personnel  management,  finances,  etc.  Challenging 
requirements  of  those  systems  include, 

♦  The  organizations  that  participate  in  a  dynamic  coalition  may  be  located  in  different  classification 
domains. 

♦  The  guidelines  for  sharing  and  exchanging  information  among  organizations  in  different  classification 
domains  are  stricter  than  those  for  organizations  in  the  same  classification  domain. 

To  address  those  problems,  the  Naval  Research  Laboratory  (NRL)  has  embarked  upon  a  research  project  to 
build  an  MLS  WFMS.  The  goal  of  the  project  is  to  develop  tools  and  security  critical  components  that 
allow  enterprises  to  harvest  emerging  commercial  off-the-shelf  (COTS)  technology  and  still  rely  on  legacy 
resources  with  reduced  risk. 

In  short,  MLS  WFMS  should  support: 

♦  Secure  interoperability  among  tasks  that  reside  in  different  classification  domains,  and 

♦  Maximum  use  of  commercial  software/hardware. 

The  need  for  a  WFMS  that  can  manage  MLS  workflows  is  immediate  and  imposes  an  implementation 
strategy  that  allows  operational  users  to  exploit  advances  in  COTS  technology  and  also  to  satisfy  their 
mission  critical  requirements.  The  multiple  single-level  architecture,  described  in  [6,7,12],  provides  the 
foundation  for  enforcing  information  flow  requirements.  A  WFMS  comprises  several  tools  and  runtime 
enactment  services.  This  paper  examines  what  properties  these  components  must  satisfy  in  a  multiple 
single-level  distributed  computing  environment.  The  MLS  workflow  design  tool  is  of  particular  interest 
because  the  commercial  tool  must  be  significantly  changed  to  represent  classification  domains.  While  this 
does  not  fit  the  paradigm  of  using  unmodified  COTS  products  with  high  assurance  security  devices,  finding 
a  research  team  that  is  developing  a  WFMS  that  supports  mission  critical  workflows  makes  it  possible  to 
develop  an  MLS  WFMS. 

In  this  paper,  we  present  requirements  for  MLS  workflows,  tools  for  supporting  MLS  workflows,  and  a 
strategy  for  implementing  them.  We  also  examine  an  MLS  workflow  model  that  supports  MLS 
cooperation,  and  describe  the  decomposition  of  an  MLS  workflow  into  multiple  single-level  workflows. 

2.  Tools  to  Support  MLS  Workflow 

A  WFMS  consists  of,  in  general,  three  components: 

♦  Workflow  design  (build-time)  tool, 

♦  Workflow  enactment  (runtime)  service,  and 

♦  Monitoring  tool. 

A  workflow  design  tool  is  a  distributed  programming  tool  with  a  graphical  user  interface.  Users  can  express 
data  dependence  and  control  flow  among  tasks  using  this  tool.  Once  a  user  specifies  the  mission  logic  (i.e., 
distributed  programming  logic),  code  for  workflow  enactment  can  be  generated.  A  workflow  enactment 
service  is  responsible  for  task  scheduling,  enforcing  dependence  among  tasks,  passing  data  from  one  task  to 
another,  and  error  recovery  based  on  the  generated  code.  The  workflow  monitoring  tool,  in  general,  tracks 
and  monitors  the  progress  of  execution. 

DoD  needs  all  the  tools  that  single-level  WHFMS  provides.  However,  DoD  requires  extra  capabilities  in 
those  tools  to  support  MLS  workflow.  We  will  examine  the  extra  requirements  for  each  tool. 
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Design  Tool  for  MLS  Workflow 


A  workflow  design  tool  is  a  distributed  programming  tool  with  a  graphical  user  interface  that  provides  the 
global  picture  of  the  whole  mission.  MLS  workflow  designers  should  be  able  to  specify  (i)  tasks  in 
different  classification  domains  and  (2)  data  and  control  dependence  (flow)  among  them.  Based  on  this 
workflow  design,  a  specification  for  workflow  runtime  can  be  generated.  Final  runtime  code  that  will  be 
securely  executed  on  an  MLS  distributed  architecture  is  generated,  based  on  this  specification.  The  runtime 
specification  and  code  generation  processes,  in  general,  depend  on  the  underlying  MLS  distributed 
architecture. 

In  MLS  applications,  each  subtask  may  be  located  in  a  different  classification  domain.  The  design  tools  for 
single-level  workflow  do  not  provide  a  capability  to  specify  classification  domains  or  compartments.  In 
other  words,  the  whole  drawing  area  of  the  workflow  design  tool  belongs  to  one  classification  domain.  It 
also  does  not  generate  runtime  code  that  can  be  executed  on  the  underlying  MLS  distributed  architecture. 
What  is  needed  is  a  design  tool  for  MLS  workflow  that: 

♦  Allows  MLS  workflow  designers  to  divide  a  design  area  into  multiple  domains, 

♦  Allows  MLS  workflow  designers  to  specify  information  flow  and  dependence  among  tasks  that  are  in 
the  same  or  different  domains,  and 

♦  Allows  MLS  workflow  designers  to  specify  dominance  relationships  among  domains  (e.g..  Top  Secret 
>  Secret  >  Unclassified). 

For  example,  a  workflow  designer  should  be  able  to  specify  an  MLS  workflow  as  in  Figure  1  where  ovals 
represent  tasks  and  arrows  represent  control  and  data  flow.  In  the  figure,  B  (begin),  S  (success),  and  F 
(failure)  represent  special  tasks. 


Figure  I :  An  Example  of  an  MLS  Workflow  Design 

Even  though  this  tool  allows  workflow  designers  to  specify  information  and  control  flow  among  tasks  in 
different  domains,  the  operational  environment  of  the  tool  will  be  system-high  (i.e.,  the  workflow  design 
tool  neither  accesses  sensitive  data  in  multiple  domains  nor  passes  it  around).  Hence,  although  this  tool  has 
to  be  trusted  in  the  sense  that  it  does  what  it  is  supposed  to  do,  it  can  be  run  on  a  single-level  system. 

MLS  workflow  has  another  functional  requirement.  When  an  MLS  workflow  is  designed,  it  must  often 
interact  with  tasks  in  other  domains  about  which  the  designer  is  not  allowed  to  know  the  details.  For 
example,  when  a  secret  workflow  designer  designs  a  workflow,  the  secret  workflow  may  need  to  send  a 
request  to  a  top  secret  task.  The  secret  designer  is  not  allowed  to  know  how  the  top  secret  task  gets  the 


129 


answer,  but  he  knows  how  to  send  a  request  and  how  to  receive  an  answer.  Hence,  the  top-secret  task,  in 
this  case,  is  a  task  foreign  to  the  secret  designer  (i.e.,  the  top  secret  task  does  not  belong  to  his  workflow). 
In  fact,  the  H  workflow  in  figure  1  may  be  designed  in  a  completely  different  organization  from  the  M 
workflow  and  the  L  workflow.  A  workflow  design  tool  for  MLS  workflow  should  be  equipped  with  the 
capability  to  model  interactions  with  a  task  for  which  only  its  interface  specification  is  known.  We  believe 
this  capability  to  model  foreign  tasks  has  broader  application,  even  for  single-level  workflows  (e.g.,  two 
cooperative  workflows  run  by  two  different  organizations). 

Enactment  Service  for  MLS  Workflow 

An  MLS  workflow  enactment  service  is  responsible  for  executing  a  workflow  in  a  correct  and  secure 
manner.  Hence,  it  depends  on  services  in  the  underlying  MLS  distributed  architecture  to  coordinate 
information  and  control  flow  among  tasks  in  different  classification  domains.  What  we  need  is  to  make 
secure  use  of  single-level  COTS  workflow  enactment  services  with  or  without  modifications.  As  we  will 
explain  in  section  3,  we  plan  to  use  multiple  single-level  workflow  enactment  services  to  execute  an  MLS 
workflow.  Since  there  will  be  no  direct  communication  among  workflow  enactment  services  at  different 
classification  domains,  there  are  no  special  MLS  requirements  for  a  workflow  enactment  service  itself.  On 
the  other  hand,  the  underlying  MLS  distributed  architecture  and  its  security  devices  must  provide  the 
necessary  assurance  for  multilevel  security. 


Monitoring  Tool  for  MLS  Workflow 

When  MLS  workflow  is  executed,  there  are  many  automatic  and  human  computer  tasks  that  are  executed  in 
different  classification  domains.  Workflow  managers  in  different  classification  domains  (there  may  be  a 
workflow  manager  per  classification  domain)  may  have  knowledge  about  tasks  in  their  classification 
domain  and  other  domains  they  are  authorized  to  access.  In  other  words,  users  of  MLS  workflow  in 
different  classification  domains  may  have  different  views  of  the  workflow  they  are  running.  Hence,  an 
MLS  WFMS  should  provide  the  ability  to  monitor  activities  in  all  domains  the  workflow  manager  is 
authorized  to  access.  Monitoring  may  include  when,  where,  and  who  performs  the  tasks  in  the  case  of 
human  tasks.  Because  the  expected,  legal  behavior  of  a  workflow  is  specified,  the  workflow  monitor  can  be 
designed  to  detect  security  critical  events  as  well  as  unexpected  behavior.  Additionally,  responses  for 
security  exceptions  can  be  specified  as  part  of  the  workflow  design. 


3.  A  Strategy  for  MLS  Workflow 

An  MLS  WFMS  should  support  functionality  equivalent  to  a  single-level  WFMS  from  the  perspective  of 
MLS  users  who  design  and  use  multilevel  workflows.  Tasks  that  may  be  single-level  individually  but 
located  in  different  classification  domains,  have  to  cooperate  to  achieve  a  higher  level  MLS  mission. 

To  provide  MLS  services  in  a  distributed  and  heterogeneous  computing  environment,  the  following 
information  flow  requirements  must  be  enforced: 

♦  High  users  must  have  access  to  low  data  and  low  resources, 

♦  High  processes  must  have  access  to  low  data,  and 

♦  High  data  must  not  leak  to  low  systems  or  users. 

An  MLS  WFMS  should  obey  this  MLS  policy.  Atluri  et  al  investigated  MLS  workflow  in  general  [13, 
14].  There  are  two  basic  ways  to  enforce  the  MLS  policy  in  MLS  workflow  systems: 

♦  Build  high-assurance  MLS  WFMS  that  will  run  on  an  MLS  platform,  or 

♦  Build  an  MLS  workflow  by  integrating  multiple  single-level  workflows  with  an  MLS  distributed 
architecture. 
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The  development  of  high-assurance  software,  necessary  to  provide  separation  between  unclassified  and 
TS/SCI  information,  such  as  MLS  workflow  systems,  has  proven  to  be  both  technically  challenging  and 
expensive.  Today’s  fast  paced  advances  in  technology  and  the  need  to  use  COTS  products  make  the 
traditional  MLS  approach  untenable.  Therefore,  we  have  chosen  the  second  approach  for  building  MLS 
WFMS.  It  is  more  in  line  with  the  modem  distributed  computing  paradigm  than  the  first  approach  in  terms 
of  supporting  autonomy  and  heterogeneity. 

To  implement  an  MLS  WFMS  using  the  architectural  method,  the  following  technical  approach  has  been 
established: 

♦  Choose  an  MLS  distributed  architecture  where  multiple  single-level  workflows  can  be  executed. 

♦  Choose  a  strategy  for  dividing  an  MLS  workflow  into  multiple  single-level  workflows. 

♦  Choose  a  single-level  WFMS  to  execute  single-level  workflow  in  each  classification  domain. 

♦  Implement  the  necessary  tools  for  supporting  MLS  workflow. 

♦  Extend  the  workflow  interoperability  model  to  accommodate  the  communication  among  workflows  at 
different  classification  domains. 

♦  Extend  the  single- level  workflow  enactment  service  to  accommodate  communication  among  tasks  in 
different  classification  domains. 


MLS  Distributed  Architecture 

Composing  an  MLS  workflow  from  multiple  single-level  workflows  is  the  only  practical  way  to  construct  a 
high-assurance  MLS  WFMS  today.  In  this  approach,  the  multilevel  security  of  our  MLS  workflow  does  not 
depend  on  single-level  WFMS  but  rather  on  the  underlying  MLS  distributed  architecture.  Thomas  and 
Sandhu  have  proposed  task-based  authorization  for  single-level  workflows  [15].  The  MLS  distributed 
architecture  will: 

♦  Host  multiple  single-level  workflows  to  be  executed  and 

♦  Provide  conduits  for  passing  information  among  tasks  in  different  classification  domains. 

Our  MLS  distributed  architecture  is  based  on  a  security  engineering  philosophy:  a  few  trusted  devices  in 
conjunction  with  information  release  and  receive  policy  servers  enforce  the  information  flow  policy  of  the 
classification  domains,  and  single-level  systems  and  single-level  engineering  solutions  provide  other 
functionality.  A  generic  MLS  distributed  architecture  is  shown  in  Figure  2. 


Switched 

workstation 


Downgrader 


Law  Network 
(Low  WFMS) 


Figure  2:  An  MLS  Distributed  Architecture 


In  this  architecture,  switched  workstations  (e.g.,  “Starlight”  [1])  enable  a  user  to  access  resources  in 
multiple  classification  domains  and  create  information  in  domains  that  the  user  is  authorized  to  access. 
One-way  devices  (e.g.,  a  flow  controller  such  as  “A  Network  Pump”  [5])  together  with  information  release 
and  receive  policy  servers  provide  a  secure  way  to  pass  information  from  one  classification  domain  to 
another.  An  information  release  policy  server  resides  in  a  classification  domain  where  the  information  is 
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released,  and  an  information  receive  policy  server  provides  a  secure  way  to  pass  information  from  one 
classification  domain  to  another  as  shown  in  Figure  3. 


Information 
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Figure  3:  Information  Release  and  Receive  Policies  in 
Conjunction  with  a  Flow  Controller 


In  general,  when  COTS  software  passes  data  to  a  flow  controller  a  wrapper  translates  the  protocol  of  COTS 
software  to  that  of  the  flow  controller  because  COTS  software  and  flow  controllers  communicate  with  other 
software  through  their  own  protocols.  Hence,  a  wrapper  can  be  considered  a  protocol  translator.  The 
detailed  description  of  the  architecture  and  the  MLS  services  are  in  [7]. 


Workflow  Interoperability 

As  we  mentioned  earlier,  our  strategy  for  implementing  an  MLS  workflow  is  through  combining  single- 
level  workflows  on  an  MLS  distributed  architecture.  Workflows  in  different  domains  may  be 
heterogeneous  and  autonomous.  Hence  workflow  interoperability  is  an  important  requirement  for  the 
approach  that  we  have  taken  to  implement  an  MLS  workflow.  Two  important  aspects  of  workflow 
interoperability  are: 

♦  Interoperability  protocol  among  independent  WMFS. 

♦  The  ability  to  model  interoperability  in  a  workflow  process  definition  tool  (i.e.,  workflow  designer). 

A  standard  body  such  as  Object  Management  Group  (OMG)  can  handle  the  first  aspect  (e.g.,  jFlow  [4]). 
However,  the  second  aspect  should  be  handled  by  each  WFMS. 

OMG’s  jFlow  introduces  two  models  of  interoperability.  They  are  nested  sub-process  and  chained 
processes  as  shown  in  Figure  4-a  and  4-b  respectively. 

In  nested  sub-process  workflow  structures,  a  task  in  workflow  A  may  invoke  workflow  B  as  the  performer 
of  a  task  and  then  wait  for  it  to  finish.  Hence,  the  task  in  workflow  A  is  a  requester,  and  the  task  that  is 
realized  by  the  sub-processes  can  serve  as  the  synchronization  point  [11]  for  interaction  of  the  two 
workflows. 
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Workflow  A 


Figure  4-a:  Nested  Sub-Process 


Workflow  B 


In  chained  workflow  structures,  one  task  may  invoke  another,  then  carry  on  with  its  own  business  logic. 
The  workflows  terminate  independently  of  each  other;  in  this  case,  the  task  registered  with  the  sub-process 
would  be  another  entity  that  is  interested  in  the  results  of  the  sub-process. 


Figure  4-b:  Chained  Processes 


Workflow  A 


Workflow  B 


The  above  two  models  provide  powerful  mechanisms  for  interoperability.  However,  we  would  like  to 
extend  these  models  to  support  an  additional  interoperability  model,  cooperative  processes.  Consider  two 
independent  autonomous  workflows  that  need  to  cooperate.  Let  us  assume  that  there  are  two  cooperating 
organizations.  Organization  A  is  in  charge  of  workflow  A  and  Organization  B  is  in  charge  of  workflow  B. 
Tasks  in  workflow  A  and  workflow  B  can  communicate  and  synchronize  with  each  other  as  shown  in 
Figure  5.  In  this  example,  two  workflows  may  have  independent  starting  and  ending  points. 


Figure  5:  Cooperative  Processes 


Workflow  A 


Workflow  B 


There  is  another  situation  that  we  want  to  support  in  the  context  of  cooperative  processes.  In  general,  the 
designer  of  workflow  A  does  not  need  to  know  the  structure  of  workflow  B  and  vice  versa.  In  conjunction 
with  MLS  principles,  the  designer  of  a  workflow  may  not  be  allowed  to  know  the  detailed  workflow 
structure  of  a  higher  level  workflow.  For  example,  in  Figure  1,  the  designer  of  the  workflow,  whose 
classification  domain  is  M,  may  not  be  allowed  to  know  the  workflow  structure  that  contains  the  TSA_H 
task. 


However,  there  is  a  minimal  set  of  information  that  is  required  for  communication  and  synchronization 
among  tasks  in  cooperating  autonomous  workflows.  This  includes: 

♦  Where  and  how  to  send/receive  requests  (i.e.,  the  location  and  invocation  method  of  tasks)  and 

♦  How  and  where  to  receive  replies  (i.e.,  expected  output  and  the  return  location). 

Therefore,  the  above  specification  has  to  appear  in  the  workflow  design  so  that  the  proper  runtime  code  can 
be  generated.  Hence,  we  need  a  primitive  that  represents  this  situation  in  the  design  tool.  This  is  the  reason 
that  we  have  introduced  foreign  tasks  in  the  workflow  model  (section  4). 
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4.  An  MLS  Workflow  Model 


Our  strategy  for  implementing  an  MLS  workflow  is  to  combine  single-level  workflows  on  an  MLS 
distributed  architecture.  We  have  chosen  the  METEOR  WFMS  [2,  3,  8,  10]  as  our  single-level  WFMS 
because  it  is  a  CORBA  compliant,  recoverable,  and  distributed  WFMS  (i.e.,  ORBWork  [10]  is  a  specific 
version  of  METEOR).  METEOR  also  supports  legacy  tasks.  It  is  an  important  feature  for  DoD  because 
DoD  has  legacy  applications  that  are  costly  to  replace  all  at  once.  Hence,  METEOR  is  a  good  starting  point 
for  extending  capabilities  to  support  MLS  workflow. 

To  accommodate  MLS  workflow,  the  METEOR  model  has  been  modified.  We  summarize  only  the  small 
subset  of  the  new  MLS  METEOR  model  necessary  for  understanding  this  paper.  A  detailed  description  of 
the  METEOR  model  can  be  found  in  [1 1]. 

In  the  METEOR  model,  a  task  represents  an  abstraction  of  an  activity.  A  task  can  be  regarded  as  a  unit  of 
work  which  is  performed  by  a  variety  of  processing  entities,  depending  on  the  nature  of  the  task.  A  task  can 
be  performed  by  ( realized  by)  a  human  or  by  a  computerized  activity  that  executes  a  computer  program,  a 
database  transaction,  or  possibly  a  network  (workflow  or  subworkflow)  of  interconnected  tasks.  Hence,  a 
task  provides  one  level  of  abstraction  (view)  and  its  realization  provides  a  lower  level  of  abstraction  (view). 
This  also  directly  maps  to  the  nested  sub-process  concept  of  jFlow.  Since  the  realization  of  a  task  may 
contain  many  tasks  at  different  levels  of  abstraction,  a  task  is  a  recursive  reference  in  the  METEOR  model. 

In  this  paper,  we  categorize  tasks  into  two  types: 

♦  Foreign  task:  A  task  whose  realization  (i.e.,  strategy  for  implementation)  is  unknown  to  the  workflow 
designer.  It  represents  a  task  that  is  a  part  of  cooperating  independent  autonomous  workflow.  It  is 
required  for  a  designer  to  declare  a  foreign  task  explicitly  to  provide  a  hint  to  the  METEOR  runtime 
code  generator.  A  foreign  task  should  have  a  minimal  information  set  that  we  specified  in  section  3 
(e.g.,  invocation,  output,  where  to  send  the  request). 

♦  Native  task:  A  task  for  which  the  realization  is  known  or  the  realization  will  be  provided  before  the 
runtime  code  generation  (i.e.,  all  other  tasks  except  the  foreign  tasks). 

A  network  task  represents  the  core  of  the  workflow  activity  specification.  Since  a  network  task  is  one  of  the 
realizations  of  a  task,  it  is  always  associated  with  a  task  called  its  parent  task.  A  single  network  of  tasks 
defines  a  relationship  among  workflow  tasks,  transferred  data,  exception  handling,  and  other  relevant 
information.  It  is  a  collection  of  either  foreign  or  native  tasks  and  transitions  from  one  task  to  another. 
Figure  6  shows  a  simplified  version  of  two  levels  of  abstractions  (views)  where  Task2  is  the  parent  task  of 
the  projected  workflow  Wi  which  contains  tasks  4,  5,  6,  and  7,  and  transition  represents  a  transition  from 
Taskl  to  Task2.  In  Figure  6,  Taskl,  Task2,  and  Task3  may  belong  to  different  classification  domains. 
Hence,  the  MLS  METEOR  model  can  be  thought  of  as  follows:  along  the  xy-plane,  there  are  tasks  in 
different  domains  and  along  the  z-axis,  there  are  different  levels  of  abstraction. 


Abstraction  level  1 


Figure  6:  MLS  METEOR  Model 
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A  task  may  play  the  role  of  a  source  task  or  a  destination  task  (e.g.,  Taskl  is  the  source  task  and  Task2  is 
the  destination  task  of  the  transition  tj  in  Figure  6)  for  a  number  of  transitions.  All  of  the  transitions  for 
which  a  task  is  the  destination  task  are  called  the  input  transitions  for  that  task  (e.g.,  transition  /y  is  an  input 
transition  for  Task2).  Likewise,  all  the  transitions  for  which  a  task  is  the  source  task  are  called  its  output 
transitions  (e.g.,  transition  tj  is  an  output  transition  of  Taskl).  A  transition  may  have  an  associated  Boolean 
condition  called  its  guard .  A  transition  may  be  activated  only  if  its  guard  is  true.  When  there  is  a  transition 
from  task  Tj  to  task  Tj,  where  T{  and  Tj  are  in  different  classification  domains,  we  call  this  an  MLS 
transition  from  Tj  to  Tj . 

An  external  transition  is  a  special  type  of  a  transition  in  which  the  two  participating  tasks  (source  and 
destination)  are  not  in  the  same  workflow  (i.e.,  transition  to  and  from  a  foreign  task).  An  implied  external 
transition  may  lead  to  a  start  task  of  another  workflow.  Similarly,  an  implied  transition  leads  from  the  final 
task  and  is  used  to  notify  the  external  entity  that  the  network  has  terminated.  Note  that  an  MLS  transition  is 
turned  into  an  external  transition  when  an  MLS  design  is  divided  into  multiple  single-level  workflows  for 
runtime. 

External  transitions  are  also  used  to  specify  synchronization  points  with  some  external  events.  Typically, 
external  transitions  may  be  used  to  specify  communication  and  synchronization  between  two  independent 
workflows.  Here,  an  external  transition  leading  into  a  task  in  the  workflow  is  assumed  to  have  an  implied 
source  task  (outside  the  workflow).  Similarly,  an  external  transition  leading  out  of  a  task  in  the  workflow  is 
considered  to  have  an  implied  destination  task  (outside  the  workflow).  External  transition  is  a  cornerstone 
of  our  strategy  to  support  MLS  workflow. 

The  classes  (i.e.,  types  of  objects)  that  are  associated  with  an  input  transition  to  a  task  are  called  the  task’s 
input  classes ,  and  those  appearing  on  an  output  transition  are  called  output  classes  of  that  task.  A  task’s 
output  class,  which  is  not  its  input  class,  is  created  by  the  task.  Specifically,  an  object  instance  of  the 
specified  class  is  created  by  the  workflow  runtime.  A  task's  input  class,  which  is  not  its  output  class,  is 
dropped  (consumed).  When  input  classes  are  unused  by  the  task,  they  are  transferred  to  the  task’s 
successor(s). 

A  group  of  input  transitions  is  called  an  AND-join  if  all  of  the  participating  transitions  must  be  activated  for 
the  task  to  be  enabled  for  execution.  An  AND-join  is  called  enabled  if  all  of  its  transitions  have  been 
activated.  All  the  input  transitions  of  a  task  may  be  partitioned  into  a  number  of  AND-joins.  A  group  of 
input  transitions  is  called  an  OR-join  if  the  activation  of  one  of  the  participating  transitions  enables  the  task. 

A  group  of  transitions  is  said  to  have  a  common  source  if  they  have  the  same  source  task  and  all  lead  either 
from: 

♦  Its  success  state  or 

♦  Its  fail  state. 

A  group  of  common  source  transitions  may  form  either: 

♦  AND-split:  Each  of  the  transitions  in  the  group  has  the  condition  set  to  true.  This  means  that  all  of 
the  transitions  in  the  group  are  activated  once  the  task  is  completed. 

♦  OR-split  (selection):  An  ordered  list  of  transitions  where  all  but  the  last  transition  may  have  arbitrary 
conditions  (i.e.,  the  last  transition  on  the  list  has  the  condition  set  to  true) .  The  first  transition  whose 
condition  is  satisfied  will  be  activated. 

♦  Loop :  A  special  case  of  an  OR-split,  where  the  list  is  composed  of  exactly  two  transitions:  loopback 
and  continue.  Loopback  implies  branch  taken  and  continue  implies  branch  not  taken  (i.e.,  fall  through). 

All  tasks  that  we  define  in  this  paper  are  single-level  tasks.  What  we  mean  by  single-level  is  that  the  task 
receives  input  from  one  classification  domain  and  produces  output  at  the  same  classification  domain.  There 
are  four  special  tasks:  begin ,  success ,  failure ,  and  synchronization.  The  synchronization  tasks  represent 
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external  transitions  to  and  from  other  workflows.  In  general,  workflow  designers  do  not  manipulate 
synchronization  nodes  directly.  They  are  automatically  generated  by  the  system  based  on  the  specification 
of  foreign  tasks  and  input  and  output  transitions  to  and  from  the  foreign  tasks. 

An  MLS  workflow  is  a  network  of  interconnected  single-level  (foreign  or  native)  tasks  from  more  than  one 
classification  domain.  Note  that  we  call  a  task  single-level  from  one  particular  level  of  abstraction  (view). 
Since  a  single-level  task  may  be  realized  by  an  MLS  workflow  at  a  lower  level  of  abstraction,  it  may  have 
side-effects  on  different  classification  domains  at  lower  abstraction  levels.  Hence,  our  distinction  between 
single-level  and  multilevel  is  purely  from  the  perspective  of  a  specific  abstraction  level. 

Let  CL(Ti)  represent  the  classification  domain  of  task  Tj.  An  MLS  workflow  that  is  the  realization  of  task 
Tj  where  CL(T0  =  Sa  must  obey  the  following  constraints: 

♦  The  begin,  success ,  and  fail  nodes  of  the  MLS  workflow  must  be  CL  (begin)  =  CL(5ucc<?s.s)  = 
CL(failure )  =  Sa. 

♦  It  may  have  tasks  in  other  classification  domains;  however,  if  the  CL(Tj)  =  Sb  where  Sa  does  not 
dominate  Sb,  then  Tj  must  be  a  foreign  task.  In  other  words,  only  tasks  in  Sc  where  Sa  >  Sc  may  have 
realizations. 

For  example,  the  workflow  in  Figure  1  is  designed  at  domain  M;  thus  special  nodes  are  located  in  domain 
M.  If  the  workflow  designer  creates  an  MLS  workflow  from  the  highest  classification  domain  with  a 
complete  view  of  the  workflow  being  designed,  then  the  complete  MLS  workflow  with  realization  of  all  its 
tasks  can  be  specified.  However,  if  the  workflow  designer  creates  an  MLS  workflow  that  requires  input 
from  (output  to)  higher  classification  domains,  then  he  may  only  know  the  interfaces  to  the  tasks  at  the 
higher  levels  but  not  the  detailed  workflow  process  at  those  levels.  In  such  cases,  foreign  tasks  can  be  used 
to  define  communication  and  synchronization  with  a  task  at  higher  classification  domains. 


5.  MLS  Dependence  and  MLS  Workflow  Decomposition 

As  we  mentioned  briefly  in  section  2,  an  MLS  workflow  design  tool  allows  MLS  workflow  designers  to: 

♦  Divide  a  design  area  into  multiple  domains, 

♦  Drop  tasks  in  different  domains,  and 

♦  Specify  data  and  control  flow  among  them. 

Once  the  design  of  an  MLS  workflow  is  completed,  the  MLS  workflow  has  to  be  divided  into  multiple 
single-level  workflows  to  be  executed  on  the  underlying  MLS  distributed  architecture  that  was  described  in 
section  3. 


MLS  Dependence 

An  MLS  workflow  design  tool  should  allow  the  same  kind  of  intertask  dependence  as  a  single-level 
workflow  design  tool  (e.g.,  guards,  input  and  output  classes).  However,  some  dependence  in  an  MLS 
workflow  may  be  specified  across  classification  boundaries  (i.e.,  MLS  dependence).  In  other  words, 
workflow  state  information  and  some  values  may  have  to  move  across  classification  boundaries  during 
workflow  execution.  Hence,  it  is  important  to  understand  what  the  vulnerability  is,  whether  it  is  easily 
exploitable  and  how  to  reduce  it. 

In  our  MLS  WFMS,  all  information  that  has  to  move  across  classification  domains  must  go  though 
information  release  and  receive  policy  servers  and  a  high-assurance  flow  controller  (e.g..  Pump  or 
downgrader  [9,16]).  We  divide  a  transition  between  two  tasks  in  different  classification  domains  into  a 
series  of  transitions.  For  example,  if  there  is  a  transition  from  a  task  in  domain  1  (TD!)  to  a  task  in  domain  2 
(TD2)  as  in  Figure  7,  then 


136 


Classification 

boundary 


Figure  7:  MLS  Transition  Across  a  Classification  Boundary 

this  transition  will  be  divided  into  transitions  from  TDi  to  PD1,  PDI  to  PD2,  and  PD2  to  TD2  as  shown  in  Figure 
8.  Note  that  there  is  the  flow  controller  between  PDJ  and  PD2  where  PDI  and  PD2  are  proxies  that  combine 
flow  controller  wrappers  and  policy  servers  (i.e.,  PDi  combines  a  flow  controller  wrapper  and  information 
release  policy  server,  and  PD2  combines  a  flow  controller  wrapper  and  information  receive  policy  server). 


Flow 

Controller 


Figure  8:  Indirect  Transition  Through  a  Flow  Controller  and  Policy  Servers 

Note  that  domain  policies  may  not  allow  combining  flow  controller  wrappers  and  information  policy 
servers.  In  that  case,  we  have  to  break  down  transitions  further.  Also  note  that  since  TDi  and  TD2  belongs  to 
two  different  workflows,  the  PDi  serve  as  synchronization  points  that  we  discusses  in  section  4. 


Decomposition  of  an  MLS  Workflow 

Using  the  method  that  we  described  above,  an  MLS  workflow  will  be  separated  into  multiple  single-level 
workflows.  The  single-level  workflows  neither  communicate  directly  nor  recognize  single-level  workflows 
from  other  classification  domains.  The  number  of  single-level  workflows  that  will  be  generated  is  equal  to 
the  number  of  classification  domains  in  the  MLS  workflow  (except  the  domains  that  contain  only  foreign 
tasks).  When  the  breakdown  is  performed,  direct  transition  (see  Figure  7)  becomes  indirect  transition  as  in 
Figure  8,  and  security  depends  on  the  underlying  MLS  architecture.  Before  we  show  an  example  of  the 
division  from  an  MLS  workflow  to  multiple  single-level  workflows,  we  will  formalize  the  MLS  workflow 
model  and  the  decomposition  of  an  MLS  workflow. 


Formalism 

An  abstraction  represents  how  we  view  a  workflow.  At  the  highest  level  of  abstraction  a  workflow  should 
be  just  one  network  task.  However,  as  we  traverse  down  the  hierarchy  of  abstractions,  workflows  become 
more  and  more  concrete  with  both  network  and  simple  tasks  making  up  connected  components  via  the 
flows.  At  the  bottom  of  this  hierarchy  of  abstractions,  there  should  be  only  simple  tasks. 

There  exists  a  partially  ordered  set  of  classification  domains  {Dj,<}  and  a  function  CL:{7asfo}u{W}  -> 

{Di}  . 

There  exists  a  set  Tasks .  (To  distinguish  the  elements  from  the  set  itself,  we  capitalize  the  set  name.)  The 
set  Tasks  can  be  distinguished  into  the  disjoint  union  of  Network  Tasks  and  Simple  Tasks.  The  set  of 

Simple  Tasks  can  be  further  decomposed  into  TT  II  NT  II  HT.  A  simple  task  can  be  thought  of  as  the 
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smallest  unit  of  work  from  the  workflow’s  point  of  view  because  it  is  only  associated  with  only  one  level  of 
abstraction.  TT  represents  transactional  tasks,  NT  are  non-transactional  tasks,  and  HT  are  human  tasks.  One 
can  think  of  a  network  task  as  a  convenient  way  to  group  tasks  that  are  associated  with  multiple  levels  of 
abstractions. 

There  also  exists  a  set  Flows.  A  flow  can  be  thought  of  as  the  order  of  program  execution  (control  and  data 
flows).  We  are  interested  in  tasks  and  flows  that  can  be  formed  into  directed  graphs  with  tasks  being  the 
vertices  and  flows  being  the  edges. 

A  workflow  W  is  a  directed  graph  made  up  of  tasks  and  flows.  {W}  is  the  set  of  workflows.  The  goal  of 
this  section  is  to  formalize  the  ideas  about  what  workflows  represent  in  the  rest  of  this  paper,  thus  ensuring 
rigor.  In  this  section  the  concept  of  “MLS”  is  implicit  in  a  workflow  or  tasks.  We  express  this  by  the 
following  definition. 


There  exists  a  set  of  Abstractions  {zhz2,  ...,  zn},  the  abstraction  levels,  with  an  ordering  <,  such  that  Zi< 
z2  <  ■"  <  zn. 

A  workflow  is  always  associated  with  an  abstraction  level  Zy  The  notation  WJ  signifies  this  association.  The 
tasks  of  Wj  are  {Nji,  N*2,...,  NJa!,  SJ!,  SJpi}  where  N\  is  a  network  task  of  WJand  SJk  is  a  simple  task 
ofWj.  For  j  =  n,  Wn  consists  of  a  single  network  task  Nnj  and  For  j  =  1,  W1  consists  only  of  simple  tasks. 

For  each  abstraction  Zy  j  >  1  there  is  a  projection  function  TTyi  which  takes  an  NJ*  of  some  WJ  and  gives  a 
workflow  Wj’!  (associated  with  Zj.i).  Furthermore  we  have  the  following: 

Non-Increasing  Security  Projection  Condition:  CL(^j.i(Nii))  <  CL(N*j),  and  this  comparison  is  well- 
defined. 

In  other  words  the  projection  of  a  network  task  of  a  workflow  will  never  give  a  workflow  of  a  higher 
classification  domain.  Note  that  there  is  no  concept  of  projection  of  a  simple  task  because  there  is  no  lower 
level  of  abstraction  for  the  simple  task. 

Starting  with  a  workflow  Wj  (associated  with  Zj)  we  may  form  the  family  of  W',  ?(Wj).  The  family  of 
gives  a  view  of  the  workflow  at  its  present,  and  all  lower,  levels  of  abstraction.  Before  making  this 
definition  precise  we  first  discuss  some  other  concepts. 

Given  Wj  we  define  Pj-i(Wj)  as 

Pj-iCW*)  =  {^j.i(Nji),  V  Nji  e  Wj},  we  may  then  form  Pj.2(Wj)  as 
Pj-2(Wj)  =  {^(N^),  V  Nj‘li  ePj.i(WJ)};  thus  we  may  recursively  define 
Pj.3(Wj),. . .,  Pi(Wj).  Now  we  are  ready  to  define  the  family  of  Wj. 

?(Wj)  =  {Wj,Pj.I(Wj),...,P1(Wi)} 

Given  any  classification  domain  Dk  we  may  form  the  filter  function  F^  as: 

FDk(?(Wi))=(VNii  eW^:  CL  (M)  =  Dk}u{  V €P>1(Wj)3:  CL  (N^)  =  Dk}u~ 
u  {V  NS  ePi(Wj)  3:  CL  (N\)  =  Dk} 

We  may  also  view  the  filter  as  a  vector  (Wj))  where  the  (j-h)-component  is 
{V  Nj-h,  e  Pj.,,(Wj)  3:  CL  (N^)  =  Dk}. 

We  have  the  following  obvious  result:  Uk  Fj (Wj»  =  ?  (W*) . 

Similarly,  we  may  also  form  Fb£)k  and  Fbj)k  by  using  network  tasks  whose  classification  is  equal  to  or 
below  Dk,  instead  of  simply  equal  to  Dk.  Note  that  it  is  possible  that  some  components  are  empty.  The 
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filter  function  provides  a  way  to  decompose  multilevel  workflow  into  single-level  workflows,  or  a  specified 
classification  domain  and  below.  Hence,  the  filter  function  provides  a  different  view  of  multilevel 
workflows  for  users  at  different  classification  domains.  For  example,  the  view  of  a  multilevel  workflow  at 
the  unclassified  level  and  the  view  of  the  same  multilevel  workflow  at  the  secret  level  are  different. 


An  Example  Decomposition 

Let  us  consider  the  simple  MLS  workflow  shown  in  Figure  1  with  classification  domains  L  <  M  <  H.  Since 
this  particular  workflow  is  designed  at  domain  M  (special  nodes,  B,  S,  and  F  signify  where  the  particular 
workflow  was  designed),  all  tasks  in  domain  M  and  L,  which  is  dominated  by  domain  M,  may  be  native 
tasks.  Since  the  designer  of  the  workflow  in  domain  M  may  not  know  the  detailed  structure  of  the 
workflow  in  domain  H,  which  dominates  M,  he  can  declare  the  TSA_H  a  foreign  task.  The  specification  of 
foreign  task  expresses  interfaces  (i.e.,  invocation  methods  and  outputs)  and  where  to  send  requests.  The 
transitions,  TSA  to  TSA_H,  TSA_H  to  Opsl,  Logistics  to  I- 1,  and  1-2  to  Opsl,  and  input  and  output  classes 
that  are  associated  with  each  transition  define  when  and  what  kind  of  data  will  be  passed  to  other 
workflows  at  different  classification  domains.  After  applying  filter  functions  FM  and  FL,  the  runtime  code 
generator  generates  the  two  workflows  as  shown  in  Figures  9-a  and  9-b.  The  shaded  proxies  in  Figure  9 
represent  the  combination  of  policy  server,  flow  controller  wrapper  and  synchronization  nodes  that 
represent  external  transitions. 


Figure  9-a:  An  Outcome  of  the  M  workflow  after  applying  filter  functions  FM 


Domain  L 


Figure  9-b:  An  Outcome  of  the  L  workflow  after  applying  filter  functions  Fl 

Note  that  workflows  in  domains  M  and  L  are  two  independent  workflows  after  the  filter  function  has  been 
applied.  The  concept  of  cooperative  processes  and  the  synchronization  node  that  we  defined  in  sections  3 
and  4  are  useful  for  interoperability  between  these  two  independent  workflows.  Also  note  that  applying  the 
filter  function  to  the  original  MLS  workflow  does  not  generate  the  workflow  in  domain  H  because  there  is 
only  a  foreign  task  in  domain  H. 


139 


6.  Conclusion 


Today's  military  is  required  to  respond  to  constantly  changing  threats  and  cooperate  with  allies  and 
different  organizations.  This  dynamic  environment  and  the  military’s  dependence  on  IT  systems  require  an 
MLS  WFMS  that  allows 

♦  Rapid  specification  and  construction  of  mission  specific  IT  systems, 

♦  Maximum  use  of  existing  or  commercial  software/hardware,  and 

♦  Secure  sharing  and  exchanging  information  among  organizations  in  different  classification  domains. 

In  this  paper,  we  presented  requirements  for  an  MLS  workflow  and  tools  needed  to  support  an  MLS 
WFMS.  An  MLS  workflow  designer  should  be  able  to  specify  different  classification  domains  and  tasks  in 
those  domains.  He  also  should  be  able  to  specify  control  and  data  flows  among  tasks  in  different 
classification  domains.  To  accommodate  this  need,  we  introduced  an  MLS  workflow  model  and  an  MLS 
workflow  design  tool. 

MLS  workflow  may  be  realized  in  many  different  ways.  However,  composing  an  MLS  workflow  from 
multiple  single-level  workflows  is  the  only  practical  way  to  construct  a  high-assurance  MLS  WFMS  today. 
Hence,  we  presented  a  strategy  for  implementing  an  MLS  workflow  by  composing  multiple  single-level 
workflows  on  a  multiple  single-level  architecture.  When  independent  multiple  single-level  workflows  work 
together  to  achieve  a  higher  mission,  workflow  interoperability  is  a  vital  element.  We  introduced  an 
extended  workflow  interoperability  model  for  that  purpose.  We  then  presented  a  method  for  decomposing 
an  MLS  workflow  design  into  multiple  single-level  workflows  for  runtime. 
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Abstract 

One  of  the  challenges  facing  the  computer  science 
community  is  the  development  of  techniques  and  tools 
to  discover  new  and  useful  information  from  large  col¬ 
lections  of  data .  There  are  a  number  of  basic  issues 
associated  with  this  challenge  and  many  are  still  un¬ 
resolved .  This  situation  has  led  to  the  emergence  of 
a  new  area  of  study  called  “Knowledge  Discovery  in 
Databases ”  (KDD). 

The  recent  efforts  of  KDD  researchers  have  focused 
primarily  on  issues  surrounding  the  individual  steps 
of  the  discovery  process.  Those  issues  that  are  not 
directly  related  to  the  discovery  process  have  received 
much  less  attention.  One  such  issue  is  the  impact  of 
this  new  technology  on  database  security.  In  this  pa¬ 
per,  we  investigate  issues  pertaining  to  the  assessment 
of  the  impact  of  classification  mining  on  database  se¬ 
curity.  In  particular ,  the  security  threat  presented  by 
a  category  of  classification  mining  algorithms  that  we 
refer  to  as  decision-region  based  is  analyzed.  Provid¬ 
ing  safeguards  against  this  threat  requires,  in  part,  the 
development  of  new  security  policies.  Our  specific  con¬ 
tributions  are  the  proposal  of  a  set  of  security  policies 
for  use  in  the  context  of  decision-region  based  classi¬ 
fication  mining  algorithms  along  with  the  specification 
and  implementation  of  a  security  risk  measure  that 
allows  for  the  realization  of  a  subset  of  the  proposed 
policies. 

1  Introduction 

Today  many  companies  and  organizations  are  collect¬ 
ing  and  storing  vast  amounts  of  data.  They  have  dis¬ 
covered  that  large  collections  of  data  often  contain 
valuable  patterns  or  rules  that  can  help  them  main¬ 
tain  their  competitive  edge.  The  development  of  tech¬ 
niques  and  tools  to  discover  valuable  patterns  or  rules 
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presents  a  variety  of  technical  challenges.  This  situa¬ 
tion  has  led  to  the  emergence  of  a  new  area  of  study 
called  “Knowledge  Discovery  in  Databases”  (KDD) 
which  has  attracted  the  interest  of  researchers  from 
a  variety  of  fields,  including  statistics,  pattern  recog¬ 
nition,  artificial  intelligence,  machine  learning,  and 
databases.  Currently,  the  primary  focus  of  KDD  re¬ 
search  is  on  issues  surrounding  the  individual  steps 
of  the  discovery  process  [1].  As  a  result,  those  issues 
that  are  not  directly  related  to  the  discovery  process 
have  received  little  or  no  attention  from  the  KDD  re¬ 
search  community.  One  issue,  in  particular,  that  has 
received  only  minimal  attention  is  the  impact  of  this 
new  technology  on  database  security. 

Chris  Clifton  and  Don  Marks  are  two  of  a  small 
number  of  researchers  who  have  examined  the  po¬ 
tential  impact  of  KDD  technology  on  database  secu¬ 
rity.  In  their  paper,  Security  and  Privacy  Implica¬ 
tions  of  Data  Mining,  Clifton  and  Marks  outline  sev¬ 
eral  very  general  strategies  designed  to  eliminate  or 
reduce  the  security  risk  presented  by  this  new  tech¬ 
nology  [2].  Their  strategies  include  allowing  users  ac¬ 
cess  to  only  a  subset  of  data,  altering  existing  data  or 
introducing  additional  (spurious)  data.  They  contend 
that  the  application  of  such  policies  is  most  effective 
in  the  context  of  specific  learning  tasks.  These  tasks 
include  classification,  estimation,  clustering,  charac¬ 
terization  and  association  [1,3,4].  Of  special  interest 
to  the  current  work  are  the  classification  mining  algo¬ 
rithms,  which  have  the  potential  to  disclose  sensitive 
information  whenever  a  database  contains  both  “sen¬ 
sitive”  and  “non-sensitive”  data  [2].  Specifically,  our 
current  work  has  focused  upon  the  need  to  develop  se¬ 
curity  policies  designed  to  minimize  or  eliminate  the 
threat  presented  by  classification  mining  in  the  con¬ 
text  of  the  relational  data  model. 

A  valid  security  policy  with  respect  to  classification 
mining  is  the  protection  of  all  the  attribute  values  of  a 
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tuple  whenever  a  tuple  includes  at  least  one  sensitive, 
or  protected ,  data  element.  That  is,  the  tuple  is  en¬ 
tirely  eliminated  from  the  user's  view.  In  general,  such 
a  policy  unnecessarily  restricts  a  user’s  access  to  the 
data.  An  alternative  policy,  which  is  the  one  we  pro¬ 
pose,  is  to  protect  only  data  elements  that  need  to  be 
concealed  in  order  to  prevent  the  disclosure  of  sensitive 
information  through  classification  mining.  This  type 
of  policy  has  the  obvious  advantage  of  allowing  maxi¬ 
mum  use  of  the  data  and  at  the  same  time  protecting 
sensitive  information.  However,  the  implementation  of 
such  a  policy  requires  an  accurate  assessment  of  the 
data  in  order  to  determine  a  protected  data  element’s 
risk  of  disclosure  and  the  need  to  conceal  additional 
data  elements. 

A  possible  assessment  strategy  in  this  case  is  to 
assess  a  protected  data  element’s  risk  of  disclosure  in 
the  context  of  a  specific  classification  algorithm.  Then, 
based  on  the  results  for  several  selected  methods,  a  de¬ 
cision  can  be  made  with  regards  to  a  protected  data 
element’s  risk  of  disclosure.  An  alternative  assess¬ 
ment  strategy  is  to  make  a  generic  assessment  of  a 
protected  data  element’s  risk  of  disclosure  that  is  in¬ 
dependent  of  a  specific  classification  method.  This 
strategy  has  a  number  of  potential  advantages  over 
the  former.  These  include: 

•  Producing  security  policies  that  are  applicable  to 
a  general  set  of  classification  methods. 

•  Providing  insight  on  how  to  modify  the  protection 
level  of  a  protected  data  element. 

•  Reducing  the  time  complexity  of  the  process  of 
assessing  the  risk  of  disclosure. 

Unfortunately,  a  completely  generic  assessment  that 
is  independent  of  a  specific  classification  method  is 
in  all  likelihood  an  impossibility  as  a  result  of  vari¬ 
ations  among  classification  mining  algorithms.  How¬ 
ever,  such  an  assessment  becomes  feasible  when  the 
scope  of  the  evaluation  is  limited  to  a  specific  group 
of  classification  algorithms  and/or  certain  restrictions 
are  placed  on  the  domain  of  the  given  attributes.  Of 
course,  the  realization  of  this  condition  requires  the 
partitioning  of  classification  algorithms  into  groups 
that  have  uniform  assessment  properties  of  a  protected 
data  element.  We  have  currently  identified  one  such 
group  of  algorithms,  which  we  will  refer  to  as  decision- 
region  based. 

The  primary  focus  of  this  paper  is  on  the  assess¬ 
ment  of  a  protected  data  element’s  risk  of  disclosure 
with  respect  to  the  decision-region  based  classifica¬ 
tion  algorithms.  To  that  end,  the  rest  of  this  paper 


is  organized  as  follows.  Section  two  presents  a  gen¬ 
eral  overview  of  classification  mining  along  with  an 
example  to  illustrate  the  security  threat  presented  by 
classification  mining  algorithms.  Section  three  pro¬ 
poses  a  set  of  security  policies  that  when  implemented 
have  the  potential  to  provide  a  high  level  of  protec¬ 
tion  against  classification  mining  and  at  the  same  time 
maximize  access  to  the  given  data.  Section  four  char¬ 
acterizes  the  decision-region  based  classification  algo¬ 
rithms  and  describes  the  uniform  assessment  proper¬ 
ties  possessed  by  this  group  of  algorithms.  Section  five 
proposes  a  security  measure  designed  specifically  for 
assessing  a  protected  data  element’s  risk  of  disclosure 
with  respect  to  the  decision-region  based  algorithms. 
Section  six  presents  an  outline  of  an  evaluation  algo¬ 
rithm,  called  Orthogonal  Boundary  (OB),  which  when 
executed  results  in  the  application  of  the  proposed  se¬ 
curity  measure  against  a  relation  instance.  The  ap¬ 
plication  of  the  measure  allows  for  the  implementa¬ 
tion  of  the  security  policies  presented  in  section  three. 
Section  seven  presents  the  results  of  experiments  that 
were  conducted  in  order  to  assess  the  validity  of  both 
the  proposed  security  measure  and  a  subset  of  the 
proposed  security  policies.  Section  eight  briefly  sum¬ 
maries  the  work  presented  in  this  paper  and  presents 
an  outline  of  future  research  projects. 

2  Classification  Mining  and 
Database  Security 

The  goal  of  classification  mining  is  to  discover  pat¬ 
terns  that  classify  objects,  or  tuples  in  the  context 
of  the  relational  data  model,  into  predefined  classes 
[1,3].  This  goal  is  achieved,  in  part,  through  the  suc¬ 
cessful  completion  of  three  specific  tasks.  One  of  the 
required  tasks  is  the  selection  of  an  attribute  from  the 
given  relation.  The  selected  attribute  is  typically  re¬ 
ferred  to  as  the  decision  variable  since  its  purpose  is  to 
partition  tuples  into  disjoint  sets  or  classes.  Another 
required  task  is  to  generalize,  if  needed,  the  current 
values  of  the  selected  decision  variable  to  form  a  set  of 
named  classes.  Table  1  shows  a  generalized  instance  of 
a  relation  in  which  the  values  of  the  decision  variable 
Mileage  have  been  replaced  by  the  class  labels,  low , 
med  and  high.  The  final  required  task  is  to  partition 
the  available  data  into  two  disjoint  sets,  a  training  set 
and  a  validation  set  [5].  The  training  set  is  analyzed 
by  a  classification  mining  algorithm  to  discover  pat¬ 
terns  that  are  relevant  to  the  classification  of  objects 
into  the  predefined  classes,  while  the  validation  set  is 
used  to  judge  the  validity  of  the  discovered  patterns. 
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Table  1:  Relation  Instance. 


Obviously,  the  generalizability  (or  predicatability)  of 
the  results  are  only  as  good  as  the  extent  of  agreement 
of  patterns  or  relationships  between  the  training  and 
validation  sets  as  judged  by  the  validation  process. 

A  well  known  category  of  classification  algorithms 
is  the  decision  tree  classifiers  [4,5,6].  These  algorithms 
are  characterized  by  the  formulation  of  a  tree  structure 
in  which  the  interior  nodes  of  the  tree  represent  tests 
of  a  single  attribute  and  the  exterior  nodes  represent 
objects  of  a  single  class.  A  test  on  an  attribute  results 
in  the  partitioning  of  objects  into  mutually  exclusive 
sets  or  outcomes.  A  simple  decision  tree  generated 
from  the  data  in  Table  1  is  shown  in  Figure  1.  This 
tree  was  generated  through  the  application  of  the  C4.5 
software  package  [6]. 

Of  course,  the  purpose  of  a  decision  tree  is  to  as¬ 
sign  a  correct  class  label  to  previously  unseen  objects. 
A  class  label  is  assigned  to  an  object  by  starting  at 
the  root  node  of  the  tree  and  advancing  downward 
through  the  tree  until  an  exterior  node  is  reached.  For 
example,  the  assignment  of  a  class  label  to  the  tuple, 
(Cyl  =  4\  Fuel  =  eft ;  Power  =  low),  results  in  the 
traversal  of  the  path  illustrated  in  Figure  1  as  a  dash 
line,  and  is  assigned  the  class  label  med.  It  is  common 
to  refer  to  the  logical  conjunction  of  attribute  name 
value  pairs,  corresponding  to  the  path  traversed,  that 
defines  the  membership  condition  of  the  correspond¬ 
ing  class  as  its  description .  In  some  cases,  it  may 
be  desirable  to  transform  a  decision  tree  into  a  set  of 
production  rules.  The  production  rules  listed  in  Ta¬ 
ble  2  were  obtained  from  the  decision  tree  in  Figure  1 
and  were  also  generated  using  the  C4.5  software  pack¬ 
age.  The  percentage  value  associated  with  each  rule 
is  C4.5’s  predicted  accuracy  of  the  rule  on  classifying 
instances  that  satisfy  the  rule's  left-hand  side. 

We  now  illustrate  how  the  disclosure  of  sensitive  in¬ 
formation  may  occur  through  the  execution  of  a  clas¬ 
sification  mining  algorithm.  Our  example  is  based  on 


Figure  1:  Decision  Tree  Generated  From  Table  1. 

the  data  shown  in  Table  3.  This  table  is.  an  extension 
of  Table  1  and  includes  the  additional  attributes  Id 
and  Prod,  along  with  the  three  additional  tuples  T15, 
T16  and  T17.  Suppose  that  the  car  company  that 
owns  the  data  has  implemented  the  following  security 
policy:  “junior  engineers  may  not  access  the  mileage 
class  of  pre-production  cars" .  This  policy  might  be  the 
result  of  company  officials  attempting  to  reduce  the 
chance  that  someone  outside  the  company  will  learn 
the  mileage  class  of  a  newly  designed  car.  As  a  result, 
company  officials  have  voluntarily  released  the  data 
shown  in  Table  4  to  all  junior  engineers.  The  only 
difference  between  Tables  3  and  4  is  the  presence  of 
NULL  values  in  the  latter  table.  In  this  instance,  a 
NULL  value,  referred  to  as  a  protected  data  element , 
protects  the  mileage  class  of  a  pre-production  car.  The 
Mileage  attribute  is  referred  to  as  the  protected  at¬ 
tribute  since  it  contains  the  protected  data  elements; 
and,  the  attributes  Id,  Fuel,  Cyl,  Power,  Prod,  and 
Tran  are  referred  to  as  non-protected  attributes  since 
they  contain  no  protected  data  elements.  Similarly, 
we  refer  to  the  tuples  that  contain  a  protected  data 
element  as  protected  tuples.  In  this  case  the  protected 
tuples  are  T15,  T16  and  T17. 

The  security  risk  presented  in  this  example  is  the 
extent  to  which  the  voluntarily  released  data  facili¬ 
tates  the  disclosure  of  a  protected  mileage  value.  The 
disclosure  of  that  information  can  be  achieved  through 
the  process  of  solving  a  classification  problem.  In 
other  words,  a  junior  engineer  may  be  able  to  correctly 
infer  a  protected  mileage  value  through  the  application 
of  a  classification  mining  algorithm  to  instances  with  a 
known  mileage  value.  For  example,  access  to  the  rule 
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Rule-1:  IF  (Cyl  =  6)  A  (Tran  =  auto)  THEN 
(Mileage  =  low)  [31.4%] 

Rule-2:  IF  (Fuel  =  2-bbl)  A  (Cyl  =  4)  THEN 
(Mileage  =  high)  [63.0%] 

Rule-3:  IF  (Cyl  =  4)  A  (Power  =  high)  THEN 
(Mileage  =  high)  [45.3%] 

Rule-4:  IF  (Fuel  =  efi)  THEN 

(Mileage  =  med)  [44.1%] _ 

Table  2:  Production  Rules  Obtained  From  Decision 
Tree  in  Figure  I. 

set  in  Table  2  would  allow  a  junior  engineer  to  infer 
with  a  relatively  high  degree  of  confidence  the  pro¬ 
tected  data  element  of  the  protected  tuple  T15  since 
this  tuple  satisfies  the  antecedent  of  Rule-2  and  the 
predicted  accuracy  of  Rule-2  is  higher  than  that  of 
a  simple  naive  prediction  that  always  predicts  a  med 
mileage  value  (since  Pr(Mileage  =  med)  =  y^).  In 
contrast,  the  risk  of  disclosure  of  the  protected  data 
element  in  tuple  TIT  is  relatively  low  with  respect  to 
the  given  rule  set  since  it  is  assigned  an  incorrect  class 
label  by  Rule-2. 

This  example  motivates  the  need  for  security  poli¬ 
cies  to  minimize  security  violation  through  classifica¬ 
tion  mining. 

3  Inference  Based  Security  Poli¬ 
cies 

It  is  possible  to  view  the  security  threat  presented  by 
a  classification  mining  algorithm  in  terms  of  the  ex¬ 
pected  occurrence  of  an  unauthorized  inference  [2]. 
Figure  2  shows  a  block  diagram  of  an  inference  sys¬ 
tem  defined  in  terms  of  a  classification  algorithm.  The 
inputs  into  the  system  are  a  set  of  tuples  having  a  de¬ 
fined  security  classification  at  or  below  some  level  X 
and  a  protected  tuple  that  contains  a  protected  data 
element  with  a  defined  security  classification  level  at 
some  level  X,  where  X  >  X.  The  output  of  the  system, 
referred  to  as  a  class-accuracy  set,  is  a  set  of  ordered 
pairs  (d,-,  a,),  where  d,*  is  the  i£A  attribute  value  (class 
label)  in  the  domain  of  the  protected  attribute,  and 
a,-  is  the  predicted  accuracy,  according  to  the  classifi¬ 
cation  mining  algorithm,  of  assigning  to  the  protected 
tuple  the  class  label  d,-.  Suppose,  for  example,  that  di, 
d2,  d3,  and  d4  are  the  attribute  values  of  a  protected 
attribute.  In  this  case,  if  a  classification  inference  sys¬ 
tem  produces  the  class- accuracy  set,  {(di,  .5),  (d2,  .2), 
(d3,  .8),  (d4,  .1)},  then  the  protected  tuple  is  assigned 
the  class  label  di,  d2,  d3  and  d4  with  predicted  accu¬ 
racy  .5,  .2,  .8  and  .1,  respectively.  In  order  to  simulate 


■WEB 

■321 

Frod. 

■raw 

■MOEErr» 

MU 

mam 

4 

■asm 

n 

manu 

med 

wm 

efi 

6 

■an 

n 

med 

am 

EBaai 

6 

in 

n 

auto 

low 

m 

■3 

«i 

ft 

■nnsni 

n 

■tifsRTni 

med 

J» 

m 

4 

■TIM 

n 

manu 

am 

s 

Si 

SI 

■ 

4 

n 

manu 

■am 

mm 

efi 

6 

in 

n 

auto 

low  1 

7 

ft 

n  ...... 

ISt^l 

KB 

3 _ 

4 

m 

n 

un 

waasm 

4 

■an 

n 

manu 

mmmm 

tia 

4 

■uMil 

n 

mi 

IntlilH 

M£fl 

m 

4 

in 

n 

auto 

■as amm 

MEM 

4 

low 

n 

manu 

Hm 

IEI 

6 

in 

n 

auto 

med  | 

am 

""4 . 

■an 

y 

auto 

■assn 

am 

W2MM 

y 

auto 

low 

Mil 

raui 

4 

low 

_i _ 

auto 

med 

Table  3:  Data  Maintained  by  Car  Company. 


the  output  of  an  inference  system,  the  predicted  accu¬ 
racy  values,  a*,  are  obtained  through  the  application 
of  a  predicted  accuracy  measure  and  in  general  their 
sum  need  not  equal  one. 

We  have  identified  two  general  criteria  for  assess¬ 
ing  the  output  of  a  classification  inference  system. 
The  first  criterion  is  based  on  a  chosen  threshold 
value.  This  criterion  involves  security  policies  that  re¬ 
quire  predicted  accuracy  values  to  be  below  a  specified 
threshold.  The  other  criterion  is  to  assess  the  output 
of  the  system  based  on  a  ranking  of  predicted  class- 
accuracy  values.  This  particular  criterion  involves  se¬ 
curity  policies  that  require  the  ranked  position  of  the 
protected  data  element  to  lie  within  a  specified  range. 
These  two  criteria  are  referred  to  as  threshold  and 
rank  criteria,  respectively. 

The  threshold  and  rank  criteria  have  led  to  the 
development  of  four  inference-based  security  policies. 
Two  of  the  four  policies,  maximum  threshold  and  max¬ 
imum  range ,  are  defined  independently  of  the  pre¬ 
dicted  accuracy  value  of  the  protected  data  element. 
Specifically,  an  instance  of  a  maximum  threshold  pol¬ 
icy  is  satisfied  for  some  threshold  value,  e,  and  for 
some  class-accuracy  set,  {(di,  ai),  (d2,  ao),  ...,  (dn, 
a^)},  if  all  a,*  (1  <  i  <  n)  are  less  than  e  .  In  this  pa¬ 
per,  “c”  is  assumed  to  represent  either  an  organization 
defined  constant,  expression  or  function  whose  value 
depends,  in  part,  on  the  desired  level  of  protection. 
The  other  type  of  security  policy,  which  is  also  de¬ 
fined  independently  of  a  protected  data  element,  called 
maximum  range,  is  satisfied  for  some  threshold  value, 
s,  and  for  some  class-accuracy  set,  {(di,  ai),  (d2,  a2), 
(dn,  an)},  if  [MAX  (ai,  a2,  &n)  -  MIN  (ai,  a2, 

a„)]  <  e.  To  illustrate  the  maximum  threshold 
and  maximum  range  policies  consider  again  the  class- 
accuracy  set,  {(di,  .5),  (d2)  .2),  (d3,  .8),  (d4,  .1)}.  In 
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this  particular  case  the  maximum  threshold  and  max¬ 
imum  range  policies  are  satisfied  (that  is,  no  violation 
of  policy)  only  if  the  specified  s-value  is  greater  than 
.8  and  .7,  respectively. 

The  remaining  two  identified  policies,  protected 
threshold  and  protected  rank ,  are  both  defined  in  terms 
of  the  predicted  accuracy  value  of  the  protected  data 
element.  In  particular,  the  protected  threshold  policy 
is  satisfied  for  some  threshold  value,  e ,  and  for  some 
class-accuracy  set,  {(d1?  ai),  (d2,  a2),  (dn,  a*)}, 
if  a*  <  £1  where  a*  is  the  predicted  accuracy  value 
associated  with  the  protected  data  element.  The  pro¬ 
tected  rank  policy  is  satisfied  for  some  class-accuracy 
set,  {(di,  ai),  (d2,  a2),  (dn,  an)},  if  the  ranked 
position  of  the  protected  data  element  is  not  within 
the  range  [L,  U],  where  L  and  U  are  positive  integers 
such  that  1  <  L  <  U  and  L  <  U  <  |{aa,  a2,  an}|. 

We  refer  to  the  interval  [L,  U]  as  the  non- secure  rank 
range.  We  illustrate  the  protected  threshold  and  pro¬ 
tected  rank  policies  using  the  previously  given  class- 
accuracy  set,  {(di,  .5),  (d2)  .2),  (d3,  .8),  (d4,  .1)}.  In 
this  case,  assuming  di  is  the  actual  value  of  the  pro¬ 
tected  data  element,  the  protected  threshold  policy  is 
satisfied,  implying  no  violation  of  policy,  only  if  the 
specified  £-value  is  greater  than  .5  and  the  protected 
rank  policy  is  satisfied  only  if  the  specified  non-secure 
rank  range  is  [L=  1,  U=l]. 

We  previously  defined  a  classification  inference  sys¬ 
tem  in  terms  of  a  specific  classification  algorithm  (Fig¬ 
ure  2).  This  definition,  however,  can  be  extended  to 
include  a  general  class  of  classification  mining  algo¬ 
rithms.  As  mentioned  in  the  introduction,  this  type  of 
generalization  requires  a  partitioning  of  classification 
algorithms  into  groups  that  have  common  properties 
that  enable  a  generic  assessment  of  the  predicted  accu¬ 
racy  values  of  a  class  accuracy  set.  In  the  next  section 


we  characterize  one  such  group  of  algorithms. 

4  Decision-Region  Based  Clas¬ 
sification  Algorithms 

Decision- region  based  classification  algorithms  share 
a  common  set  of  properties  that  give  rise  to  a  uni¬ 
form  assessment  of  the  predicted  accuracy  values  of  a 
class  accuracy  set.  Before  stating  these  properties,  we 
first  characterize  the  decision-region  based  class  of  al¬ 
gorithms.  A  classification  algorithm,  A,  is  a  decision- 
region  based  algorithm  if  and  only  if  the  following  two 
conditions  are  satisfied: 

•  Condition- 1 :  It  is  possible  to  identify  a  priori  a 
finite  set  of  descriptions,  D,  in  terms  of  the  prop¬ 
erties  present  in  an  object  0  such  that  the  par¬ 
ticular  description  d  used  by  A  to  classify  O  is  an 
element  of  D. 

•  Condition-2 :  The  predicted  accuracy  of  assigning 
an  object  O  satisfying  a  description  d  G  D  to  a 
class  C  is  dependent  on  the  distribution  of  class 
label  C  relative  to  all  class  labels  associated  with 
the  objects  that  satisfy  d. 

The  first  condition  leads  to  the  property  that  the 
effective  assessment  of  the  security  risk  for  decision- 
region  based  classification  algorithms  requires  explicit 
or  implicit  determination  of  the  predicted  accuracy 
values  of  the  class-accuracy  set  associated  with  each 
description  d  G  D.  The  second  condition  enables  us  to 
select  a  particular  method  of  computing  the  predicted 
accuracy  values  of  a  class-accuracy  set.  In  general, 
inference-based  security  policies  may  be  applied  at  two 
levels.  If  it  is  known  a  priori  that  a  particular  descrip¬ 
tion  d  will  be  selected  relative  to  the  protected  tuple 
in  a  protected  relation,  then  we  can  apply  a  policy  just 
to  that  description.  This  case  is  referred  to  as  the  de¬ 
scription  level  security  policy.  This  form  of  evaluation 
is  possible  only  if  we  wish  to  do  the  assessment  for  a 
particular  classification  algorithm.  An  alternative  to 
this  approach  is  referred  to  as  description  space  level 
security  policy.  In  this  case,  we  must  ensure  that  a 
chosen  security  policy  is  satisfied  no  matter  which  d  is 
chosen  by  a  class  of  classification  algorithms. 

Given  the  above  definitions  and  Condition-1,  we 
concluded  that  the  specification  of  inference-based 
security  for  decision-region  based  classification  algo¬ 
rithms  should  be  carried  out  at  the  description  space 
level.  In  the  following  section,  we  propose  a  measure 
for  computing  the  predicted  accuracy  values  of  a  class- 
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Protected  Tuple  (with 
a  protected  element  classified  — 
at  a  level  greater  than  L). 

Training  Instances  (classified  ^ 

at  a  level  less  than  or  equal  to 
L). 

Figure  2:  Classification  Inference  System- 

accuracy  set  with  respect  to  an  arbitrary  decision- 
region  based  classification  algorithm. 

5  Computing  Predicted  Accu¬ 
racy  Values 

The  proposed  measure  for  computing  the  predicted  ac¬ 
curacy  values  of  a  class- accuracy  set  in  the  context  of 
a  decision-region  based  algorithm  is  as  follows.  Let  C 
be  a  class  label  in  the  domain  of  a  protected  attribute. 
Given  a  description  d  £  D,  the  predicated  accuracy  a* 
of  assigning  the  protected  tuple  T  the  label  C  is  the 
ratio  of  the  number  of  tuples  that  are  assigned  label 
C  and  satisfy  d  to  the  number  of  tuples  that  satisfy  d. 
The  proposed  measure  is  equivalent  to  the  classifica¬ 
tion  accuracy  measure  defined  in  [7]. 

We  now  illustrate  the  application  of  the  measure 
using  the  description,  (Fuel  =efi )  A  (Cyl  =  4)>  ap¬ 
plied  against  Table  1.  In  this  instance  there  are  zero 
tuples  with  a  low  gas  mileage  label  that  satisfy  the 
description,  three  tuples  with  a  med  gas  mileage  label 
that  satisfy  the  description,  and  two  tuples  with  a  high 
gas  mileage  label  that  satisfy  the  description.  Thus, 
the  predicted  accuracy  value  for  low ,  med  and  high 
is  0.0,  0.6  and  0.4,  respectively.  In  the  next  section, 
we  present  the  Orthogonal  Boundary  (OB)  algorithm, 
which  is,  in  part,  designed  to  compute  the  class  accu¬ 
racy  values  with  respect  to  an  arbitrary  description  d 
£  D  that  might  be  chosen  by  a  specific  subset  of  the 
decision-region  based  algorithms. 

6  Orthogonal-Boundary  (OB) 
Algorithm 

The  Orthogonal-Boundary  (OB)  algorithm  has  been 
designed  for  use  with  decision-region  based  classifica¬ 
tion  algorithms  that  produce  a  specific  type  of  class 
description.  In  particular,  we  require  that  each  de¬ 
scription,  d  £  D,  be  a  logical  conjunction  of  attribute 
name  value  pairs  that  are  sufficient,  but  may  or  may 


not  be  necessary.  This  type  of  description  is  produced 
by  decision  tree  classifiers. 

It  follows  that  the  set  of  such  descriptions  D,  with 
respect  to  a  protected  tuple  T,  is  the  set  of  all  logical 
conjunctions  formed  from  one  or  more  non-protected 
attribute  name  value  pairs  that  appear  in  T.  We  refer 
to  this  set  of  descriptions  as  the  description  space,  D*, 
of  the  protected  tuple  T.  To  illustrate  the  formulation 
of  a  description  space,  D*,  consider  the  following  pro¬ 
tected  tuple:  (Fuel  =  efi ;  Cyl  =  4\  Tran  =  manu ; 
Mileage  =  null).  In  this  case,  D*  is  the  set  of  log¬ 
ical  expressions:  {(Fuel  =  efi),  (Fuel  =  efi)  A  (Cyl 
=  4),  (Fuel  =  efi)  A  (Tran  =  manu),  (Cyl  =  4)  A 
(Tran  =  manu),  (Cyl  —  4)^  (Tran  =  manu),  (Fuel  = 
efi)  A  (Cyl  =  4)  A  (Tran  =  manu)}.  It  follows  from 
Condition-1  that  the  assignment  of  a  class  label  to 
this  tuple,  by  a  decision-region  based  algorithm  that 
produces  a  description  space  equivalent  to  D*,  is  nec¬ 
essarily  a  label  that  it  associates  with  one  of  the  seven 
listed  descriptions. 

Obviously,  there  is  no  way  to  identify  a  priori  the 
description  d  £  D*  chosen  by  a  classifier  without 
making  explicit  assumptions  about  the  operation  of 
such  an  algorithm.  Unfortunately,  the  number  of  de¬ 
scriptions  belonging  to  a  protected  tuple’s  description 
space,  D*,  is  exponential  in  terms  of  the  number  of 
non-protected  attributes.  There  are,  however,  several 
conditions  that  can  be  taken  advantage  of  to  reduce 
the  number  of  inspected  descriptions  (e.g.  reduce  the 
size  of  the  search  space). 

One  condition  is  the  recognition  of  a  special  set  of 
descriptions  that  we  refer  to  as  “zero”  descriptions. 
The  classes  constructed  from  these  descriptions  con¬ 
tain  no  tuples  with  a  class  label  corresponding  to  the 
protected  data  element.  The  recognition  of  a  zero  de¬ 
scription  implies  that  there  is  no  need  to  inspect  any 
description  that  is  a  specialization  of  the  zero  descrip¬ 
tion  since  the  resulting  class  will  also  contain  zero  in¬ 
stances  of  the  protected  data  element.  Suppose  that 
the  description  (Tran  =  manu)  is  a  zero  description 
with  respect  to  the  protected  tuple,  (Fuel  =  efi;  Cyl  = 
4;  Tran  =  manu ;  Mileage  =  null).  In  this  situation, 
there  is  no  need  to  inspect  the  descriptions:  (Fuel  = 
efi)  A  (Tran  =  manu),  (Cyl  =  4)  A  (Tran  =  manu), 
and  (Fuel  =  efi)  A  (Cyl  =  4) 

Another  condition  that  can  also  reduce  the  num¬ 
ber  of  inspected  descriptions  is  the  transformation  of 
a  non-secure  description  into  a  secure  description.  A 
description  is  considered  secure  if  its  computed  class- 
accuracy  set  satisfies  the  chosen  security  policy.  Based 
on  our  measure  of  predicted  accuracy  and  either  a  pro¬ 
tected  threshold  or  protected  rank  security  policy,  a 
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transformation  of  a  non-secure  description  into  a  se¬ 
cure  description  requires  a  percentage  reduction  in  the 
number  of  tuples  satisfying  the  description  with  a  class 
label  equal  to  the  protected  data  element.  Obviously, 
such  a  reduction  occurs  when  either  the  number  of  tu¬ 
ples  satisfying  the  description  with  a  class  label  equal 
to  the  protected  data  element  is  decreased,  or  the 
number  of  tuples  satisfying  the  description  with  a  class 
label  that  is  not  equal  to  the  protected  data  element 
is  increased.  A  possible  transformation  scheme,  espe¬ 
cially  when  the  objective  is  to  maximize  the  amount 
of  accessible  data  without  altering  non-protected  data 
values,  is  to  “protect”  additional  values  of  the  pro¬ 
tected  tuple  so  as  to  prevent  the  assignment  of  the  tu¬ 
ple  to  the  class  defined  by  the  non-secure  description. 
This  particular  solution  has  the  added  benefit  of  re¬ 
ducing  the  required  number  of  inspected  descriptions. 
For  example,  if  (Cyl  =  4)  is  a  non-secure  description 
with  respect  to  the  protected  tuple,  (Fuel  =  efi;  Cyl 
=  4  J  Tran  =  manu ;  Mileage  =  null),  then  by  denying 
the  tuple  membership  to  the  set  defined  by  (Cyl  =  4) 
there  is  no  need  to  inspect  the  descriptions:  (Fuel  = 
efi )  A  (Cyl  =  4),  (Cyl  =  4)  A  (Tran  =  manu),  (Fuel 
—  efi  )  A  (Cyl  =4)  A  (Tran  =  manu). 

Unfortunately,  the  protection  of  additional  at¬ 
tribute  values  of  a  protected  tuple  T,  in  general, 
causes  a  decision-region  based  algorithm  to  violate 
Condition- 1  in  the  assignment  of  a  class  label  to  tu¬ 
ple  T.  Such  a  case  occurs  in  the  application  of  C4.5’s 
"consult”  interpreter  which  is  designed  to  classify  pre¬ 
viously  unseen  tuples  based  on  a  constructed  decision 
tree  and  to  output  a  ranking  of  the  possible  class  la¬ 
bels  that  correspond  to  the  tuple.  A  feature  of  the 
"consult”  interpreter  is  its  ability,  through  the  use  of 
conditional  probabilities,  to  assign  a  class  label  to  a 
tuple  that  contains  unknown,  or  protected,  attribute 
values.  It  is  this  latter  feature  that  potentially  results 
in  a  violation  of  Condition-1  since  the  assignment  of 
a  class  label  to  a  protected  tuple  T  may  not  be  based 
on  a  description  d  E  D*.  An  alternative  scheme  to 
transforming  a  non-secure  description  into  a  secure 
description  is  to  protect  a  subset  of  attribute  values 
not  belonging  to  the  protected  tuple.  This  solution 
requires  the  protection  of  attribute  values  such  that 
a  decrease  occurs  in  the  number  of  tuples  satisfying 
the  non-secure  description  with  a  class  label  equal  to 
that  of  the  protected  data  element.  The  advantage 
of  the  alternative  scheme  is  that  it  ensures  that  the 
assignment  of  a  class  label  to  a  protected  tuple  satis¬ 
fies  Condition-1 ;  however,  this  scheme  does  not  sup¬ 
port  maximum  access  to  the  data.  The  current  im¬ 
plementation  of  the  OB  algorithm  adheres  to  the  first 


transformation  scheme,  the  protection  of  additional 
attribute  values  of  the  protected  tuple. 

A  third  condition  that  can  reduce  the  number  of  in¬ 
spected  descriptions  is  the  establishment  of  an  upper 
bound  on  the  number  of  descriptions.  By  statically  or 
dynamically  protecting  a  subset  of  a  protected  tuple’s 
non-protected  attribute  values,  we  can  reduce  the  size 
of  the  tuple’s  description  space.  Of  course,  the  disad¬ 
vantage  of  such  a  strategy  is  that  it  does  not  guarantee 
maximum  access  to  the  data. 

A  conceptual  version  of  the  OB  algorithm  is  shown 
in  Figure  3.  A  k-description  represents  a  descrip¬ 
tion  defined  in  terms  of  k  attributes.  Each  iteration 
through  the  outer  loop  generates  a  set  of  descrip¬ 
tions  that  require  inspection.  The  inner  loop  con¬ 
sists  of  a  nested-if  statement  that  evaluates  the  se¬ 
curity  status  of  a  description.  If  a  zero-description 
is  faced  then  conceptually  all  specializations  of  that 
description  are  identified  and  placed  onto  the  “zero- 
description”  list.  Otherwise,  if  a  description  is  non- 
secure  then  the  attributes  comprising  the  description 
are  identified  and  placed  onto  the  “candidate-protect” 
list.  The  non-secure  descriptions  identified  at  level  k 
are  transformed  into  secure  descriptions  following  the 
inspection  of  all  k-descriptions.  The  current  imple¬ 
mentation  of  the  OB  algorithm  requires  human  assis¬ 
tance  in  performing  the  transformations.  Specifically, 
the  algorithm  displays  a  list  of  all  non-secure  descrip¬ 
tions  at  level  k  and  prompts  the  user  (the  person  re¬ 
sponsible  to  set  security  policies)  to  select  an  appropri¬ 
ate  set  of  the  protected  tuple’s  non-protected  attribute 
values  to  conceal.  The  objective  is  to  conceal  a  set  of 
non-protected  attribute  values  that  deny  the  protected 
tuple’s  membership  to  the  individual  sets  defined  by 
the  k-level  non-secure  descriptions  and  at  the  same 
time  maximize  the  amount  of  accessible  data.  The  re¬ 
sult  of  executing  the  OB  algorithm  is  the  implicit  or 
explicit  inspection  of  a  protected  tuple’s  description 
space.  The  inspection  process  ensures  that  all  descrip¬ 
tions  belonging  to  the  tuple’s  description  space  satisfy 
the  user’s  specified  description  level  security  policy. 


7  Experimental  Investigation 

In  this  section,  experiments  are  conducted  to  vali¬ 
date  a  proposed  approach  to  establish  security  poli¬ 
cies  based  on  the  proposed  class-accuracy  measure  and 
their  results  are  reported.  The  objective  of  the  experi¬ 
ments  is  to  test  the  following  hypothesis:  there  exist  a 
protected  threshold  policy  or  a  protected  rank  policy 
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Algorithm  OB 
Input: 

T  =  protected  tuple 
R  =  relation 

Initialization: 

zerojist  =  { } 
candidate_protect Jist  =  { } 
protect_attrJist  =  { } 
k  =  1 

A  =  {  r  is  an  element  of  k-description  |  (r  has  no  attributes  belonging  to  protect_attrJi$t 
&  (r  is  not  an  element  of  zero_list) } 

Loop  until  (A  is  empty) 

Loop  for  each  (r  element  of  A) 

If  (r  —  "zero"  description)  Then 
Append  all  specializations  of  r  to  zerojist 
Else 

If  (r  =  "non-secure"  description)  Then 
Append  all  attributes  of  r  to  candidate_protectJist 
Endif 
Endloop 

If  (candidate_protectJist  is  not  empty)  Then 
Transform  "non-secure"  description  into  "secure"  description 
Update  protected_attrJist 
Initialize  candidate_protectJist  =  { } 

Endif 
k  =  k  +  1 

A  =  {r  is  an  element  of  k-description  |  (r  has  no  attributes  belonging  to  protect_attrJist) 

&  (r  is  not  an  element  of  zerojist) } 

Endloop 


Figure  3:  Orthogonal  Boundary  (OB)  Algorithm. 


applied  at  the  description  level  that  produces  a  pro¬ 
tected  rank  policy  at  the  description  space  level  with 
a  non-secure  rank  range  of  [L  =  1,  U  =  1].  In  other 
words,  we  wish  to  identify  a  description  level  protected 
threshold  policy  and/or  a  protected  rank  policy  that, 
when  applied  to  the  individual  descriptions  of  a  pro- 
tected  tuple's  description  space,  results  in  an  appro¬ 
priate  description  space  level  protected  rank  policy. 
In  general,  the  determination  as  to  whether  a  specific 
description  space  level  policy  has  been  successfully  im¬ 
plemented  must  be  based  on  an  evaluation  of  the  out¬ 
put  from  one  or  more  decision-region  based  algorithms 
that  have  been  applied  to  the  protected  tuple.  In  con¬ 
ducting  the  experiments,  we  restricted  the  evaluation 
of  the  description  space  level  protected  rank  policy,  [L 
=  1,  U  =  1],  to  the  C4.5  decision  tree  classifier.  The 
application  of  the  classifier  is  described  in  the  next 
section. 

We  anticipate  that  the  implementation  of  the  de¬ 
scription  space  level  protected  rank  policy,  [L  =  1,  U 
=  1],  will  provide  a  high  level  of  protection.  This  state¬ 
ment  is  based  on  the  assumption  that  a  user  will  assign 
the  protected  tuple,  or  more  specifically  the  protected 
data  element,  the  class  label  that  is  assigned  the  top 
rank  by  the  chosen  decision-region  based  algorithm. 
In  addition,  the  non-secure  rank  range,  [L  =  1,  U  = 
1],  introduces  a  relatively  high  degree  of  uncertainty  in 
a  user’s  assignment  of  a  class  label  to  a  protected  tu¬ 
ple.  This  is  because,  even  a  user  who  has  knowledge  of 
the  fact  that  the  implemented  description  space  level 
protected  rank  policy  is  [L  =  1,  U  =  1]  can  only  logi¬ 
cally  eliminate  from  consideration  the  class  label  that 
has  been  assigned  the  top  rank  by  the  decision-region 
based  algorithm.  Hence,  a  user  is  at  best  forced  to 
make  a  random  guess  from  n  -  1  class  labels;  where  n 
is  the  number  of  possible  labels. 


7  A  Experimental  Parameters 

The  execution  of  the  experiments  required  the  con¬ 
struction  of  several  'protected  relation  instances.  We 
define  a  protected  relation  instance  as  a  relation  con¬ 
sisting  of  at  least  one  non-protected  attribute  and  ex¬ 
actly  one  protected  data  element.  A  relation  instance 
that  contains  n-protected  data  elements  is  viewed  as 
n-instances  of  a  protected  relation.  The  protected 
relations  used  in  this  investigation  were  constructed 
through  the  insertion  of  a  protected  tuple  into  non¬ 
protected  relation  instances  constructed  through  the 
execution  of  the  Synthetic  Classification  Data  Set 
(SCDS)  program  [8].  A  total  of  four  non-protected 


relation  instances  were  constructed  through  the  use  of 
the  program  and  each  instance  was  produced  with  the 
parameter  values  shown  in  Table  5.  The  values  of  an 
irrelevant  attribute  have  only  a  random  relationship 
with  the  decision  variable;  and,  a  masked  relevant  at¬ 
tribute  is  an  attribute  whose  values  have  a  direct  rela¬ 
tionship  with  the  decision  variable,  but  the  attribute 
itself  is  not  included  as  part  of  the  relation. 

The  protected  tuples,  unlike  the  non-protected  re¬ 
lation  instances,  were  manually  generated  from  ran¬ 
domly  selected  attribute  values.  Specifically,  six  pro¬ 
tected  tuples  were  constructed  with  respect  to  Rela¬ 
tion  #1,  six  with  respect  to  Relation  #2,  four  with 
respect  to  Relation  #3,  and  five  with  respect  to  Re¬ 
lation  #4.  Thus,  a  total  of  twenty-one  protected  re¬ 
lation  instances  were  generated.  Each  protected  tu¬ 
ple  was  evaluated  against  a  set  of  protected  threshold 
and  protected  rank  policies  applied  at  the  description 
level.  The  implemented  protected  threshold  policies 
included  those  defined  at  an  e-value  of  0.9,  0.8,  0.7, 
0.6,  0.5,  0.4,  0.3,  0.2,  and  0.1;  and,  the  implemented 
protected  rank  policies  included  those  defined  at  a 
non-secure  rank  range  of  [L  =  1,  U  =  1],  [L  =  1,  U  =  2], 
[L  =  1,  U  =  3]  and  [L  =  1,  U  =  4].  These  description 
level  policies  were  applied  to  each  protected  tuple,  T, 
through  the  execution  of  the  OB  algorithm.  The  re¬ 
sult  in  each  case  was  the  transformation  of  a  protected 
tuple,  T,  into  a  protected  tuple  T*  such  that  each  de¬ 
scription,  d,  belonging  to  T ’s  description  space  D* 
satisfied  the  stated  policy  as  defined  in  section  three. 
In  general,  the  implementation  of  the  individual  de¬ 
scription  level  policies  resulted  in  a  protected  tuple, 
T  ,  that  contained  multiple  protected  attribute  val¬ 
ues. 

In  order  to  assess  the  generality  of  the  imple¬ 
mented  description  level  policies,  two  distinct  decision 
tree  models  were  generated  for  each  of  the  four  non¬ 
protected  relation  instances.  One  set  of  models  corre¬ 
sponded  to  the  gain  attribute  selection  criterion,  while 
the  other  set  of  models  corresponded  to  the  gain  ra¬ 
tio  attribute  selection  criterion  [6].  These  two  criteria 
are  both  supported  by  C4.5  and  provide  a  decision  rule 

for  selecting  the  interior  nodes  of  a  decision  tree.  Each 
w  / 

protected  tuple  T  was  evaluated  against  instances  of 
both  models  using  C4.5’s  “consult”  interpreter  [6].  In 
conducting  the  experiments,  an  attribute  value  was 
specified  as  unknown  if  the  interpreter  requested  a 
protected  attribute  value. 

7.2  Experimental  Results 

The  results  of  the  experiments,  with  respect  to  nine¬ 
teen  of  the  twenty-one  protected  relation  instances, 
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are  shown  in  Tables  6-10.  Tables  6-9  display  the 
average,  highest  and  lowest  rank  positions  of  the  pro¬ 
tected  data  elements  across  all  nineteen  protected  re¬ 
lation  instances.  Specifically,  Tables  6  and  7  display 
statistics  about  the  rank  positions  produced  by  the 
‘'consult’’  interpreter  when  applied  to  the  individual 
protected  tuples  that  were  generated  by  the  applica¬ 
tion  (description  level)  protected  threshold  policies  us¬ 
ing  the  OB  algorithm.  Tables  8  and  9  display  the 
same  statistics  for  the  rank  positions  produced  by  the 
“consult”  interpreter  when  applied  to  the  individual 
protected  tuples  that  were  generated  from  the  appli¬ 
cation  (description  level)  protected  rank  policies  using 
the  OB  algorithm.  Table  10  displays  the  percentage  of 
attribute  values  (among  which  all  but  one  were  non¬ 
protected),  belonging  to  the  individual  protected  tu¬ 
ples,  that  were  mandated  to  be  protected  through  the 
execution  of  the  OB  algorithm  in  order  to  satisfy  the 
various  (description  level)  protected  threshold  policies 
and  the  protected  rank  policies  shown.  It  is  interest¬ 
ing  to  note  that  the  protected  rank  policies  resulted 
in  a  relatively  high  percentage  of  protected  attribute 
values  as  compared  to  the  protected  threshold  policies. 

The  recorded  rank  positions  in  Table  6  state  that 
a  (description  space  level)  protected  rank  policy  that 
is  satisfied  by  the  non-secure  rank  range,  [L  =  1,  U  = 
1],  is  realizable  through  the  application  of  a  (descrip¬ 
tion  level)  protected  threshold  policy  defined  at  either 
a  threshold  value  (f)  of  0.4  or  0.5.  In  addition,  the 
recorded  rank  positions  indicate  that  a  (description 
level)  protected  threshold  policy  defined  at  an  s- value 
other  than  0.4  or  0.5  produces  an  undeftnable  (descrip¬ 
tion  space  level)  protected  rank  policy  as  a  result  of  a 
maximum  recorded  rank  position  of  one.  The  results 
recorded  in  Table  7  are  almost  identical  to  the  results 
recorded  in  Table  6.  The  only  significant  difference  is 
that  a  (description  space  level)  protected  rank  policy 
that  is  satisfied  by  the  non-secure  rank  range,  [L  = 
1,  U  =  1],  is  realizable  through  the  application  of  a 
(description  level)  protected  threshold  policy  defined 
at  a  threshold  value  (e)  of  0.2  as  well  as  0.4  and  0.5. 

The  recorded  rank  positions  in  Table  8  state  that 
a  (description  space  level)  protected  rank  policy  that 
is  satisfied  by  the  non-secure  rank  range,  [L  =  1,  U  = 
1],  is  realizable  through  the  application  of  a  (descrip¬ 
tion  level)  protected  rank  policy  defined  with  respect 
to  either  the  non-secure  rank  range  [L  =  1,  U  =  2] 
or  [L  =  1,  U  =  3].  The  remaining  (description  level) 
protected  rank  policies  listed  in  Table  8  produced  un- 
definable  (description  space  level)  protected  rank  poli¬ 
cies.  Surprisingly,  the  results  recorded  in  Table  9  are 
significantly  different  from  those  in  Table  8.  In  partic¬ 


ular,  the  recorded  rank  positions  in  Table  9  state  that 
a  (description  space  level)  protected  rank  policy  that 
is  satisfied  by  the  non-secure  rank  range,  [L  =  1,  U  = 
I],  is  realizable  through  the  application  of  a  (descrip¬ 
tion  level)  protected  rank  policy  defined  with  respect 
to  either  the  non-secure  rank  range  [L  =  1,  U  =  1] 
or  [L  =  1.  U  =  3].  Again  the  remaining  (description 
level)  protected  rank  policies  listed  in  Table  9  pro¬ 
duced  undefinable  (description  space  level)  protected 
rank  policies. 

7.3  Experimental  Conclusions 

If  the  assumption  is  made  that  a  valid  protected  rank 
policy  (description  space  level)  is  one  defined  with  re¬ 
spect  to  a  non-secure  rank  range,  [L  =  1,  U  =  1],  then 
a  valid  protected  rank  policy  is  achievable  based  on 
the  above  results  through  the  application  of  either  a 
(description  level)  protected  threshold  policy  defined 
at  a  threshold  value  (e)  of  approximately  0.45  or  a 
(description  level)  protected  rank  policy  defined  with 
respect  to  the  non-secure  rank  range  [L  =  1,  U  = 
3].  The  implementation  of  the  (description  level)  pro¬ 
tected  rank  policy  with  a  non-secure  rank  range,  [L  = 
1,  U  =3],  resulted  in  a  substantially  higher  percent¬ 
age  of  protected  attribute  values  having  to  be  hidden 
than  did  the  implementation  of  the  (description  level) 
protected  threshold  policy  defined  at  an  e- value  of  0.4 
or  0.5.  We  suspect  that  when  a  (description  level) 
protected  threshold  policy  is  defined  in  terms  of  ei¬ 
ther  a  relatively  high  £-value  (0.9,  0.8,  0.7,  or  0.6) 
or  a  relatively  high  non-secure  rank  range  ([L  =  1, 
U  =  1]  or  [L  =  1,  U  =  2]),  the  percentage  limit  on 
the  number  of  tuples  with  a  class  label  equal  to  the 
protected  data  element  is  insufficient  to  ensure  an  ade¬ 
quate  level  of  protection  at  the  description  space  level. 
On  the  other  hand,  description  level  protected  thresh¬ 
old  policies  defined  in  terms  of  a  low  £-value  (0.3,  0.2, 
or  0.1)  or  a  low  protected  rank  policy  ([L  =  1,  U  =  4]) 
over  protect  the  protected  data  element.  As  a  result, 
the  assignment  of  a  class  label  to  a  protected  tuple 
is  based  entirely  upon  the  dominant  relationships,  or 
patterns,  that  exist  within  the  data,  independent  of 
the  accessible  attribute  values  of  the  protected  tuple. 

The  two  protected  relation  instances  not  repre¬ 
sented  in  Tables  6  -  10  are  exceptions  to  the  notion 
of  a  valid  (description  space  level)  protected  rank  pol¬ 
icy  defined  in  terms  of  a  (description  level)  protected 
threshold  policy  or  a  protected  rank  policy.  Specifi¬ 
cally,  the  rank  position  of  the  two  tuples’  protected 
data  element  as  specified  by  the  “consult”  interpreter 
consistently  occupied  the  top  position  across  all  im¬ 
plemented  (description  level)  protected  threshold  and 
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Table  5:  Parameter  Values  Used  to  Construct  Non-Protected  Relation  Instances. 


Table  6:  Rank  Positions  With  Respect  to  Protected  Threshold  Policies  (Gain  Ratio  Criterion). 


Table  7:  Rank  Positions  With  Respect  to  Protected  Threshold  Policies  (Gain  Criterion). 
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Table  8:  Rank  Positions  With  Respect  to  Protected  Rank  Policies  (Gain  Ratio  Criterion). 
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Table  9:  Rank  Positions  With  Respect  to  Protected  Rank  Policies  (Gain  Criterion). 
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protected  rank  policies.  We  refer  to  such  protected  re¬ 
lation  instances  as  inherently  non-secure.  In  the  case 
of  such  a  relation  instance  the  only  logical  course  of 
action  is  to  entirely  eliminate  the  protected  tuple  from 
the  user’s  view.  Our  preliminary  work  (not  reported 
in  this  paper)  in  this  area  indicates  that  such  rela¬ 
tion  instances  are  avoidable  if  the  transformation  of 
a  non-secure  description  to  a  secure  description  is  ac¬ 
complished  by  protecting  additional  attribute  values 
not  belonging  to  the  protected  tuple  (no  violation  of 
Condition- 1 );  or,  such  relation  instances  may  be  iden¬ 
tifiable  through  the  application  of  an  alternative  pred¬ 
icated  class-accuracy  measure. 

8  Conclusion  and  Future  Work 

The  work  presented  in  this  paper  concerned  the  ac¬ 
curate  assessment  of  a  protected  data  element’s  risk 
of  disclosure  with  respect  to  the  decision-region  based 
classification  mining  algorithms.  To  that  end,  a  new 
set  of  security  policies  were  developed  for  use  in  this 
context  along  with  the  specification  and  implementa¬ 
tion  of  a  security  risk  measure  that  allows  for  the  re¬ 
alization  of  a  subset  of  the  proposed  policies.  A  set  of 
experiments  were  also  conducted  in  order  to  validate 
the  overall  quality  of  the  proposed  approach.  Based 
on  the  results,  we  have  concluded  that  a  valid  security 
policy  is  indeed  achievable  using  the  approach  pre¬ 
sented  in  this  paper. 

We  have  several  research  projects  planned  with  re¬ 
spect  to  this  new  and  challenging  research  area.  Our 
immediate  plans  include,  addressing  the  issue  of  in¬ 
herently  non-secure  relation  instances,  improvement  of 
the  efficiency  of  the  OB  algorithm,  mapping  of  contin¬ 
uously  valued  attributes  on  to  the  description  space, 
D*,  of  a  protected  tuple,  and  development  of  addi¬ 
tional  security  measures  for  other  groups  of  classifica¬ 
tion  mining  algorithms. 


Description  Level  Policies 

Protected  Att.(, 

Protected  Threshold  (c)  =  0.9 

29.6 

Protected  Threshold  (c)  =  0.8 

30.4 

Protected  Threshold  (c)  =  0.7  ~~~~ 

31.2 

Protected  Threshold  (r)  =  0.6 

33.6 

Protected  Threshold  (s)  =  0.5 

36.0 

Protected  Threshold  (c)  =  0.4 

43.0 

Protected  Threshold  (c)  =  0.3 

52.2 

Protected  Threshold  (c)  =  0.2 

66.4 

Protected  Threshold  (s)  =  0.1 

89.3 

Non-Secure  Rank  Range 

L  =  1,  U  =  1 

54.9 

Non-Secure  Rank  Range 

L  =  1,  U  =  2 

68.4 

Non-Secure  Rank  Range 

L  =  1,  U  =  3' 

76.3 

Non-Secure  Rank  Range 

L  =  1,  U  =  4 

83.4 

Table  10:  Percentage  of  Protected  Attributes  Across 
All  Protected  Relation  Instances. 
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Abstract 

Data  mining  introduces  new  problems  in  database 
security.  The  basic  problem  of  using  non-sensitive 
data  to  infer  sensitive  data  is  made  more  difficult  by 
the  “probabilistic”  inferences  possible  with  data  min¬ 
ing.  This  paper  shows  how  lower  bounds  from  pattern 
recognition  theory  can  be  used  to  determine  sample 
sizes  where  data  mining  tools  cannot  obtain  reliable 
results. 

1  Introduction 

The  problem  of  inference  has  received  considerable 
attention  in  the  database  security  community.  The 
basic  problem  is  using  non-sensitive,  or  “low”,  data 
to  infer  sensitive,  or  “high”  facts.  As  an  example,  we 
may  want  to  keep  the  presence  of  a  particular  type 
of  equipment  (e.g.,  “super-secret  aircraft”  (SSA))  at  a 
particular  location  (“Secret  Base”,  SB)  secret.  How¬ 
ever,  to  support  logistics  we  want  to  make  information 
about  supplies  needed  by  all  bases  available.  The  in¬ 
ference  problem  occurs  if  parts  that  are  only  used  for 
the  SSA  are  ordered  by  SB  -  from  this  we  can  infer 
that  there  must  be  a  SSA  at  SB. 

Most  of  the  work  in  preventing  inference  in  multi¬ 
level  secure  databases  has  concentrated  on  preventing 
such  “provable”  facts  [4].  Recent  work  has  extended 
this  to  capturing  data-level,  rather  than  schema-level, 
functional  dependencies  [16].  However,  data  mining 
provides  what  could  be  viewed  as  probabilistic  infer¬ 
ences.  These  are  relationships  that  do  not  always  hold 
true  (are  not  a  functional  dependency),  but  hold  true 
substantially  more  often  than  would  be  expected  in 
“random”  data.  Preventing  this  type  of  inference  de¬ 
tection  is  beyond  the  reach  of  existing  methods. 

As  an  example,  what  if  there  are  no  parts  that  are 
used  only  for  the  SSA?  The  functional  dependency  in¬ 
ference  problem  no  longer  exists.  However,  there  may 
be  some  items  that  are  used  more  heavily  by  the  SSA 
than  other  aircraft  (e.g.,  it  uses  a  great  quantity  of 


fuel).  Data  mining  could  find  such  a  relationship;  for 
example  bases  X,  Y,  and  SB  use  an  unusual  quantity 
of  fuel  in  relation  to  other  supplies.  If  we  know  that 
bases  X  and  Y  support  the  SSA,  we  can  make  a  good 
guess  that  SB  does  as  well. 

Hinke  and  Delugach  [8,  9]  give  a  breakdown  of  in¬ 
ference  into  seven  classes  of  problems.  The  first  six 
rely  on  combining  known  rules  (e.g.,  Part  A  is  only 
used  on  an  SSA)  with  non-sensitive  data  (Part  A  was 
suppled  to  base  SB)  to  infer  sensitive  facts.  Class  7 
is  the  inference  of  a  sensitive  rule.  It  is  noted  that 
this  “represents  a  considerably  different  target  than 
the  previous  ones” ,  and  as  a  result  has  received  con¬ 
siderably  less  attention  in  the  database  security  com¬ 
munity.  However,  one  of  the  primary  focuses  of  data 
mining  technology  is  inferring  rules,  with  the  rise  of 
data  mining  technology,  this  has  become  a  recogniz¬ 
able  problem. 

What  can  we  do  about  this,  in  particular  when  we 
don’t  know  what  the  adversary  will  be  looking  for? 
We  can  ensure  that  any  results  will  be  suspect.  If  we 
can  convince  the  adversary  that  any  “guess”  (inferred 
rule)  gained  from  data  mining  is  no  more  likely  to  be 
a  good  guess  than  a  random  guess,  the  adversary  will 
not  be  able  to  trust  any  data  mining  results. 

How  do  we  do  this?  Inferences  from  data  mining 
have  some  level  of  confidence  and  support.  We  will 
show  how  to  ensure  that  either: 

1.  The  rules  “discovered”  may  be  incorrect  (the  lev¬ 
els  of  confidence  and  support  could  be  signifi¬ 
cantly  off);  or 

2.  It  is  likely  that  rules  exist  with  higher  confidence 
and  support  than  those  found. 

We  propose  to  accomplish  this  by  ensuring  that  the 
data  available  to  the  adversary  is  only  a  sample  of  the 
data  on  which  the  adversary  would  like  the  rules  to 
hold  (note  that  in  some  cases  this  “sample”  may  be 
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an  entire  database,  as  long  as  the  “inferences”  we  wish 
to  protect  against  apply  to  a  larger  population  than 
that  reflected  in  the  database).  We  show  that  we  can 
draw  a  relationship  between  the  sample  size  and  the 
likelihood  that  the  rules  are  correct. 

We  base  this  on  the  fact  that  inference  rules  can  be 
used  to  classify.  Vapnik[14]  has  shown  error  expecta¬ 
tions  in  classification  on  samples.  This  is  due  to  ex¬ 
pectations  of  a  random  sample  of  a  population  having 
a  different  distribution  with  respect  to  any  classifica¬ 
tion  information  than  the  population  as  a  whole.  If  we 
can  show  that  a  “best  possible”  classifier  is  likely  to 
be  incorrect,  we  can  work  back  to  show  that  any  rules 
(at  best  a  “best  possible”  classifier)  will  also  likely  be 
incorrect. 

We  divide  this  into  two  variations: 

1.  We  are  concerned  with  protecting  a  particular 
“object”  (e.g.,  any  relationship  where  the  target 
is  a  single  value  for  a  given  variable).  Note  that 
we  do  not  require  predefining  the  value.  We  can 
reduce  the  problem  of  learning  a  binary  classifier 
to  this. 

2.  We  are  concerned  with  a  particular  class  of  rules 
(e.g.,  inference  rules  involving  a  single  indepen¬ 
dent  variable).  This  limits  our  space  of  possible 
classifiers. 

As  we  will  show;  these  two  variations  lead  to  different 
solutions. 

1.1  What  this  work  will  lead  to 

The  eventual  goal  of  this  work  is  to  provide  a  tool 
usable  by  security  administrators.  This  tool  would 
enable  the  administrator  to  determine: 

•  The  allowable  size  of  a  sample,  given  constraints 
on  the  quality  of  what  an  adversary  would  be  al¬ 
lowed  to  learn;  and 

•  The  quality  of  what  an  adversary  would  be  al¬ 
lowed  to  learn,  given  the  size  of  a  sample. 

To  make  this  a  usable  tool,  we  must  be  able  to  abstract 
away  from  technical  details  of  learning/data  mining 
algorithms.  We  view  certain  information  as  clearly 
reasonable  for  a  security  administrator  to  provide: 

\D\  The  number  of  items  in  the  database  (or  in  the 
“world”  about  which  we  are  concerned;  if  we 
are  concerned  about  the  application  of  discovered 
knowledge  to  the  real  world,  and  the  database  is 
already  only  a  sample  of  the  real  world). 

n  The  number  of  items  in  the  sample  (unless  this  is 
the  goal  of  our  calculation). 


Attributes  The  number  and  type  (e.g.,  continuous, 
discrete  with  k  possible  values)  of  attributes  for 
the  entities  in  the  data. 

Note  that  this  assumes  a  “single  table”  view  of  the 
data;  this  matches  current  data  mining  technology. 
For  a  complete  database,  independent  analyses  can  be 
performed  for  each  table  (or  collection  of  tables  that 
describe  a  single  type  of  entity). 

We  need  other  information  that  is  more  difficult  to 
provide,  part  of  the  focus  of  this  work  is  defining  this 
information  in  a  form  reasonable  for  security  admin¬ 
istrators. 

Mining  type  To  obtain  tight  bounds  on  error  given  a 
sample,  we  need  to  know  the  descriptive  power  of 
the  adversary’s  data  mining  technology.  This  can 
be  assumed  to  be  “worst  case” ,  however  if  the  se¬ 
curity  administrator  knows  the  type  of  knowledge 
that  needs  to  be  protected  against  (e.g.,  inference 
rules  that  can  classify  the  data  into  two  groups) 
we  can  obtain  better  bounds. 

Expected  error  To  give  a  recommendation  on  sam¬ 
ple  size,  we  need  to  know  the  expected  error  we 
plan  to  force  an  adversary  to  live  with.  This  can 
be  difficult;  for  example  for  an  inference  rule  that 
does  binary  classification,  a  statement  like  “The 
rule  must  be  wrong  25%  of  the  time”  would  be 
unreasonable  if  90%  of  the  cases  belonged  to  one 
class.  Better  descriptions  might  be  “There  is  a 
25%  expectation  that  the  actual  best  rule  will  be 
better  than  the  best  rule  found  on  the  sample”, 
or  “The  actual  confidence  of  any  rule  can  be  ex¬ 
pected  to  have  25%  error”. 

Note  that  the  means  for  describing  expected  error 
will  be  dependent  on  mining  type;  one  possibility 
would  be  to  have  a  security  administrator  provide 
error  for  one  type  and  have  the  system  determine 
expected  error  for  other  types  of  mining. 

This  paper  will  only  provide  rudimentary  examples 
of  how  such  a  security  administration  tool  would  ap¬ 
pear.  The  focus  is  on  establishing  sample  size/error 
relationships  for  a  simple  class  of  problems  (binary 
classification),  and  giving  an  example  of  how  this  may 
be  extended.  There  is  clearly  substantial  room  for 
further  work  in  this  area. 

1.2  Applications  and  problem  extensions 

Providing  a  random  sample  of  data  has  limited  util¬ 
ity.  A  few  examples  of  where  this  has  utility  are: 

•  Development:  We  can  provide  a  sample  of 
real  data  to  a  system  developer  to  use  in  de¬ 
sign/testing.  This  allows  the  developer  to  do 
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a  better  job  of  testing,  without  clearing  them 
for  access  to  the  entire  database.  This  re¬ 
quires  clearing  the  data  items  and  checking  for 
functional-dependency  type  inferences,  but  these 
alone  would  not  be  sufficient.  The  techniques  pre¬ 
vented  here  are  necessary  to  ensure  that  such  a 
“sanitized  sample”  doesn't  contain  hidden  rules. 

•  Damage  assessment:  If  a  portion  of  the  database 
is  released,  we  can  analyze  potential  effects  of 
that  release. 

However,  certain  extensions  of  this  work  could  gen¬ 
erate  substantial  additional  utility.  For  example,  we 
may  want  to  give  access  to  a  subset  of  the  database 
-  a  non-random  sample.  This  clearly  will  allow  facts 
to  be  learned  with  respect  to  that  subset,  but  can 
we  use  this  approach  to  state  limits  on  what  can  be 
learned  that  is  not  specific  to  that  subset?  Alterna¬ 
tively,  can  we  give  query  access,  but  “cut  off”  access 
before  too  much  is  released.  This  requires  tracking 
access  over  time,  as  a  collection  of  small  independent 
samples  must  be  treated  as  a  single  large  sample  for 
our  purposes.  This  is  a  problem  faced  with  all  infer¬ 
ence  protection  mechanisms,  Marks[ll]  solves  this  for 
“normal”  inference  with  a  mechanism  for  tracking  and 
limiting  what  a  given  user  has  seen  over  time. 

2  Motivating  Example 

In  this  section  we  will  give  a  more  detailed  presen¬ 
tation  of  the  “inference  through  supply  orders”  exam¬ 
ple,  along  with  a  “proof  by  example”  of  how  providing 
only  a  sample  of  the  data  can  be  used  to  prevent  data 
mining  from  making  the  inference  base  SB  is  likely  to 
support  an  SSA  due  to  similar  ordering  patterns  to 
bases  X  and  Y. 

First,  let  us  assume  that  the  complete  order 
database  is  as  presented  in  Table  1.  If  we  were  to 
look  for  a  classification  of  Item  in  this  table,  we  would 
find  the  rules: 

If  Location =X  then  Item=Fuel  (confidence 
100%,  support  29%) 

If  Location=Y  then  Item=Fuel  (confidence 
100%,  support  14%) 

If  Location=SB  then  Item=Fuel  (confidence 
100%,  support  29%) 

Armed  with  this  knowledge,  we  can  search  for  reasons 
why  X  and  Y  order  only  Fuel  (other  reasons  that  dif¬ 
ferentiate  them  from  A  and  B).  If  we  find  a  common 
factor  (e.g.,  they  support  the  SSA),  we  can  make  a 
good  guess  that  SB  also  has  this  common  factor. 

Note  that  if  we  only  have  a  sample  of  the  database, 
we  may  develop  a  different  set  of  rules.  Table  2  gives 


Table  1:  Base  Order  Database 


Date 

Location 

Item 

1/1/97 

SB 

Fuel 

1/1/97 

X 

Fuel 

1/2/97 

Y 

Fuel 

1/4/97 

A 

Fuel 

1/6/97 

B 

Food 

1/10/97 

B 

Food 

1/18/97 

A 

Food 

1/22/97 

Ha 

Food 

1/24/97 

B 

Fuel 

l"/31/97 

X 

Fuel 

2/3/97 

SB 

Fuel 

Table  2:  Sample  of  Base  Order  Database 


Date 

Location 

Item 

1/1/97 

SB 

Rjel 

1/1/97 

X 

Fuel 

1/4/97 

A 

Fuel 

1/6/97 

B 

Food 

1/10/97 

B 

Food 

1/24/97 

MB 

Fuel 

1/31/97 

X 

Fuel 

2/3/97 

SB 

Fuel 

a  database  containing  70%  of  the  complete  database. 
The  rules  generated  from  this  database  are: 

If  Location=A  then  Item=Fuel  (confidence 
100%,  support  17%) 

If  Location =X  then  Item=Fuel  (confidence 
100%,  support  33%) 

If  Location=SB  then  Item=Fuel  (confidence 
100%,  support  33%) 

If  we  looked  for  common  factors  between  Locations 
A  and  X  (that  differentiated  them  from  others),  we 
would  not  find  the  “threatening”  evidence  that  they 
both  support  the  SSA.  Thus  we  have  preserved  the 
secrecy  of  the  SSA  at  SB. 

Note  that  there  are  a  number  of  problems  with  this 
example: 

1.  Note  that  the  support  of  the  first  rule  is  low.  If 
the  adversary  were  to  ignore  rules  with  support 
below  20%  (in  both  cases),  it  might  still  be  pos¬ 
sible  to  obtain  the  desired  information  (although 
with  less  confidence,  as  the  presence  of  the  base  Y 
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supporting  the  SSA,  but  not  present  in  the  rule, 
would  lessen  the  impact  of  this). 

2.  What  if  we  chose  a  different  sample?  It  is  easy 
to  find  samples  that  would  improve  the  rules,  and 
increase  the  adversary's  ability  to  find  the  desired 
information. 

3.  Does  this  sample  database  still  provide  the  de¬ 
sired  information  (e.g.,  an  audit  of  order  deliv¬ 
eries,  or  supporting  the  improvement  of  logistics 
through  better  prediction  of  ordering  needs)? 

Problem  3  is  difficult  -  we  must  know  the  intended 
purpose  of  the  data  to  determine  if  the  sample  is  suf¬ 
ficient.  Some  purposes  (such  as  prediction  of  ordering 
needs)  are  particularly  problematic:  If  we  aim  to  pre¬ 
vent  an  adversary  from  learning  rules  we  don’t  even 
know  about ,  we  will  necessarily  prevent  learning  any 
rules.  However,  if  the  goal  relies  on  specific  data  items, 
rather  than  inferences  among  the  data  items  (such  as 
comparing  specific  orders  with  their  delivery  traces), 
we  need  only  ensure  that  the  desired  items  are  pro¬ 
vided.  We  must  be  careful,  though,  to  avoid  problem  2 
by  letting  the  adversary  choose  the  sample.  Although 
not  the  focus  of  this  paper,  we  will  return  to  this  issue 
in  the  conclusions. 

What  we  address  is  problem  1.  If  we  can  show  that 
the  rules  with  high  support  or  high  confidence  on  the 
sample  do  not  necessarily  have  high  support  and  con¬ 
fidence  on  the  complete  database ,  then  the  adversary 
cannot  rely  on  the  rules  produced  from  the  sample. 
It  is  our  goal  to  show  not  that  the  rules  obtained  on 
the  sample  are  bad,  but  that  they  are  likely  to  be 
bad.  The  sample  may  or  may  not  cause  unreliable  re¬ 
sults.  If  the  adversary  knows  this,  the  confidence  in 
the  rules  produced  (and  in  any  knowledge  gained  us¬ 
ing  those  rules)  becomes  suspect.  All  we  have  to  do  is 
lower  the  adversary's  confidence  in  the  results  to  the 
point  where  the  adversary  would  view  any  informa¬ 
tion  gained  from  data  mining  on  the  sample  to  not  be 
worth  the  effort  required  to  verify  it.  In  other  words, 
although  any  knowledge  gained  using  the  rules  may 
be  correct,  it  may  also  be  incorrect  and  thus  cannot 
be  trusted. 

The  goal  of  this  work  is  to  show  that  we  can  con¬ 
vince  the  adversary  of  the  likelihood  of  such  a  fail¬ 
ure,  without  knowing  the  problem  the  adversary  wants 
to  solve .  Many  data  mining  techniques  (including 
the  production  rules  shown  above)  produce  rules  or 
knowledge  that  can  be  used  to  classify  items  in  the 
database.  Vladimir  Vapnik  has  shown  error  limits  in 
classification  when  the  classification  is  learned  from  a 
sample[14].  In  Section  4,  we  will  use  an  adaptation  of 


Vapnik’s  work  to  show  the  difficulty  of  learning  as  a 
function  of  sample  size. 

To  give  an  idea  of  how  this  would  work  in  practice, 
we  will  use  the  results  shown  in  the  next  two  sections 
to  demonstrate  how  large  a  sample  would  be  reason¬ 
able  for  the  above  example. 

Assuming  there  are  at  most  two  food  and/or  fuel 
orders  per  month,  and  that  the  adversary  attempts  to 
predict  using  the  number  of  orders  of  each  type  per 
month,  e.g.,  a  rule  is  of  the  form: 

January(Fuel ,  2)& January(Food7  0)& 
February (. . .  =>  Supports  SSA 

Further  assume  that  using  a  collection  of  such  rules  we 
can  develop  a  “perfect”  classifier  (one  that  will  always 
give  us  the  right  result).  If  we  are  willing  to  tolerate 
that  with  a  50%  probability,  the  learned  classifier  can 
be  expected  to  be  wrong  40%  of  the  time,  we  can  allow 
a  sample  size  of  over  175  billion  where  a  single  sample 
is  all  of  the  orders  for  a  given  base  for  a  year  (based 
on  Theorem  1;  we  will  discuss  how  these  numbers  are 
derived  in  Section  4.1).  This  is  large,  but  the  reason  is 
that  there  are  a  great  many  possible  rules  (3  possible 
values  for  each  of  food  and  fuel  gives  9  possible  val¬ 
ues  per  month;  or  9 12  possible  values  a  year).  If  the 
sample  doesn't  contain  an  exact  instance  of  a  rule,  the 
classifier  won’t  know  if  it  applies.  Thus  the  need  for 
a  large  sample  size.  This  is  a  problem  with  complex 
classifiers  -  they  don’t  generalize  well. 

The  problem  for  the  adversary  is  that  there  are 
likely  to  be  too  many  ways  to  classify  any  sample  - 
we  are  assuming  that  the  adversary  will  be  looking  for 
rules  based  on  exact  numbers  of  each  type  of  order.  If 
we  assume  that  a  simple  correct  classifier  exists,  and 
that  the  adversary  has  the  sense  to  look  for  a  simple 
classifier,  we  have  more  serious  constraints.  In  particu¬ 
lar,  if  we  assume  N  (the  number  of  possible  classifiers) 
is  6: 

1.  fuel  »  food,  low  total  order  for  the  year 

2.  fuel  «  food,  low  total  order 

3.  fuel  «  food,  low  total  order 

4.  fuel  >>  food,  high  total  order 

5.  fuel  «  food,  high  total  order 

6.  fuel  <<  food,  high  total  order 

we  can  only  allow  a  sample  size  of  (6  —  l)/(4  *  .4)  =  3 
(again,  a  sample  is  complete  information  on  a  base  for 
a  year,  or  72  tuples  from  a  complete  version  of  Table 

i.) 


Figure  1:  Distance  between  best  classifier  on  sample 
and  best  classifier  on  data. 

This  assumes  a  perfect  classifier  exists,  however 
with  a  simple  classifier  it  is  unlikely  that  it  can  per¬ 
fectly  classify  the  data.  If  the  best  possible  classifier 
has  some  error,  it  is  more  difficult  to  state  exactly 
what  we  mean  by  the  error  of  the  classifier  learned 
from  the  sample.  We  will  now  give  some  more  detail 
on  error  estimation.  In  Section  4  we  discuss  the  spe¬ 
cific  theorems  that  allow  us  to  determine  these  bounds; 
we  will  then  return  to  discussion  of  this  example. 

3  Basic  Ideas  of  Error  Estimation 

Our  purpose  in  this  section  is  to  show  how  we  can 
control  the  expected  error  of  a  classifier  by  limiting 
sample  size.  Figure  1  gives  an  idea  of  the  problem.  We 
want  to  control  (by  varying  the  sample  size)  the  error 
D  between  the  classifier  the  adversary  can  expect  to 
learn  from  the  sample  and  the  “best  possible”  (Bayes) 
classifier.  Note  that  the  space  of  possible  classifiers 
C  may  not  include  the  Bayes  classifier.  Therefore  the 
error  is  composed  of  two  components:  The  approxima¬ 
tion  error  Da  between  the  best  classifier  Lc  available 
in  C  and  the  Bayes  classifier  L*,  and  the  estimation 
error  De  between  the  classifier  Ln  learned  from  the 
sample  and  Lc.  The  primary  difficulty  is  that  there 
are  many  possible  “best  classifiers”  Ln  depending  on 
the  sample.  Thus  our  goal  is  to  analyze  the  expected 
value  E {D}  of  the  error  with  respect  to  the  sample 
size. 

There  are  actually  three  types  of  error: 

Bayes  Error:  This  is  the  expected  error  of  the  “best 
possible”  classifier  on  the  entire  database.  If  the 
output  is  a  function  of  the  input,  this  is  0.  This 
is  entirely  dependent  on  the  data,  and  as  such  we 


can  say  little  without  knowing  specifically  what 
we  want  to  protect  against. 

Approximation  Error:  This  is  the  difference  be¬ 
tween  the  expected  error  of  the  best  classifier  from 
the  types  of  classifiers  we  are  considering,  e.g.,  de¬ 
cision  trees,  and  the  Bayes  classifier.  The  more 
complex  the  classifier,  the  lower  the  expected  ap¬ 
proximation  error. 

Estimation  Error:  This  is  the  difference  in  expected 
error  between  a  classifier  learned  from  a  sample 
and  the  best  classifier  available.  This  is  what  we 
can  control  by  varying  the  sample  size. 

Various  theorems  show  that  classifiers  exist  that 
will  learn  “perfectly”  given  a  sufficiently  large  sam¬ 
ple,  i.e., 

ELn  -»  L*. 

However,  the  classifier  chosen  may  be  dependent  on 
the  data  or  on  n,  for  example  this  holds  for  a  nearest 
neighbor  classifier  if  the  number  of  classes  k  — ►  oo  and 
k/n  — >  0  ([12]). 

There  are  various  things  we  might  like  to  say: 

1.  Given  an  error  estimate,  that  error  estimate  will 
be  off  (different  from  the  Bayes  error)  by  some 
amount  e  with  probability  5. 

2.  The  expected  difference  between  a  learned  classi¬ 
fier  and  the  Bayes  error  is  at  least  e  with  proba¬ 
bility  5. 

3.  Given  a  sample,  the  error  of  the  learned  classifier 
can  be  expected  to  differ  from  the  best  classifier 
of  that  type  by  e  with  probability  5. 

4.  Given  a  type  of  classifier,  we  can  expect  the  best 
possible  classifier  of  that  type  to  differ  from  the 
Bayes  error  by  e  with  probability  S. 

Item  1  gives  a  lower  bound  -  it  says  that  even  if  the 
adversary  “guesses”  a  great  classifier,  the  adversary’s 
estimate  of  how  good  the  classifier  is  (using  the  sam¬ 
ple)  will  likely  be  off.  However,  this  is  not  likely  to 
be  a  tight  bound  on  the  actual  problem:  what  the  ad¬ 
versary  can  learn.  Likewise  4  isn’t  all  that  interesting; 
it  says  how  good  a  classifier  is  possible,  but  nothing 
about  what  can  be  learned  from  the  sample. 

We  will  address  3,  the  estimation  error.  Figure  2 
gives  an  idea  of  the  goal:  given  a  circle  of  radius  e, 
we  want  to  choose  a  sample  size  such  that  with  prob¬ 
ability  S ,  the  best  classifier  on  the  sample  L„  will  be 
outside  the  circle.  If  Ln  is  outside  the  circle,  then  at 
least  e  percent  of  the  time  Ln  will  give  the  “wrong” 
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Figure  2:  Error  of  best  classifier  on  sample  Ln  worse 
than  best  classifier  Lc  by  more  than  £. 

answer,  even  though  a  classifier  Lc  exists  that  would 
give  the  right  answer. 

We  will  also  see  that  the  formulas  for  estimation 
error  are  dependent  on  approximation  error,  giving  a 
way  of  estimating  2. 

4  Limits  based  on  Sample  Complexity 

The  sample  complexity  of  a  problem  is  the  size  of 
sample  needed  to  ensure  that  the  expected  error  of 
a  classifier  learned  from  the  sample  is  within  given 
bounds.  The  probability  that  a  classifier  is  outside 
the  given  bounds  allows  us  to  look  at  two  issues: 

1.  The  likelihood  that  a  different  outcome  is  better 
for  the  given  left-hand  side  of  the  rule,  and 

2.  The  likelihood  that  a  better  rule  exists  for  the 
same  outcome;  i.e.,  a  better  predictor  for  the  same 
result  (lack  of  a  good  rule  for  the  given  outcome, 
bases  that  support  the  SSA,  is  the  benefit  gained 
from  a  small  sample  in  Section  2). 

■> 

What  we  can  show  is  the  following:  Given  a  “best 
error”  that  we  are  willing  to  tolerate,  and  a  minimum 
probability  that  the  adversary  will  not  be  able  to  do 
better  than  that  error,  what  is  the  largest  sample  we 
can  allow?  In  this  case,  “best  error”  is  a  measure 
of  the  difference  between  the  classifier  (rule  set)  the 
adversary  chooses,  and  the  best  possible  classifier  of 


that  type .  Note  that  this  is  dependent  on  the  type  of 
classifier;  i.e.,  for  a  very  simple  classifier  it  is  easy  to 
get  the  “best”  one  (but  the  best  one  probably  won’t  be 
very  good).  What  we  are  bounding  is  the  estimation 
error. 

Formally,  we  are  determining  the  sample  complex¬ 
ity  N(e,  £),  defined  as  the  smallest  integer  n  such  that 

sup  P{L(0n)  -  Lc>  e}  <5 
(X,Y)ex 

where  Lc  is  the  best  classifier  in  C : 

Lcd=  inf 

<p£C 

and  L(gn)  is  the  classifier  selected  based  on  the  train¬ 
ing  data: 

L(gn)  =  P {9n{X)  ±  Y\((XU  Yi), . . . ,  (Xni  Yn))} 

This  states  that  there  is  a  distribution  of  the  data 
such  that  if  the  sample  size  n  <  N(e,  5),  then  with 
probability  at  least  6 ,  a  classifier  exists  that  outper¬ 
forms  the  chosen  one  by  at  least  e.  The  key  factor 
here  is  that  there  is  a  distribution  of  the  data  where 
this  holds.  This  doesn’t  mean  a  specific  choice  of  the 
sample  is  necessary;  the  dependence  is  instead  on  the 
characteristics  of  the  data  as  a  whole.  There  exists  a 
distribution  of  the  data  such  that  the  bounds  will  hold 
on  average  across  all  random  samples  of  the  data.1 

We  begin  with  two  definitions  of  Vapnik- 
Chervonenkis  theory[14]  (notation  from  [6]):  First  we 
define  the  shatter  coefficient  of  the  classifier: 

Definition  1  Let  A  be  a  collection  of  measurable  sets. 
For  (zi,...,jZn)  e  {3^}n,  let  Na(z\,.  . .  ,zn)  be  the 
number  of  different  sets  in 

{{z1,...,zn}f]A;AeA}. 

The  n-th  shatter  coefficient  of  A  is 

s(A  n)  =  ,  max  AU(zi, . . . ,  z„). 
(zll...7zn)e{^d}n 

That  is,  the  shatter  coefficient  is  the  maximal  number 
of  different  subsets  of  n  points  that  can  be  picked  out 
by  the  class  of  sets  A . 

1One  such  distribution  is  skewed  based  on  the  classifier:  most 
of  the  data  conforms  to  a  single  rule  left-hand  side.  This  is  not 
an  unreasonable  distribution  to  expect  in  practice.  For  example, 
if  we  assume  that  the  information  leading  to  a  sensitive  inference 
is  a  relatively  small  part  of  the  database,  we  are  likely  to  have 
this  type  of  distribution. 
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Definition  2  Let  A  be  a  collection  of  sets  with  \  A\  l_ 
2.  The  largest  integer  k  >  1  for  which  $(A,k)  = 
2*  is  denoted  by  V4,  and  it  is  called  the  Vapnik- 
Chervonenkis  dimension  (or  VC  dimension)  of  the 
class  A.  If  s(A ,  n)  =  2n  for  all  n,  then  by  definition , 
VA  =00. 

We  can  see  that  the  shatter  coefficient  of  the  clas¬ 
sifier  must  be  less  than  or  equal  to  the  number  of 
distinct  rule  sets  =  2numberof  rules?  Since  the  vc- 
dimension  is  the  largest  k  such  that  the  shatter  co¬ 
efficient  =  2fc,  we  can  see  that  the  vc-dimension  for 
binary  decision  rules  is  the  number  of  distinct  rules.2 3 
Looking  back  at  the  example  of  Section  2,  if  we  say 
that  we  are  trying  to  learn  if  a  base  supports  the 
SSA  based  on  the  number  of  fuel  and  food  orders  in 
a  year,  and  we  assume  at  most  two  orders  of  each 
type  per  month,  we  can  see  that  for  a  year  there  are 
24  *  24  possible  rules,  so  the  VC  dimension  =  576.  If 
we  were  to  allow  a  more  complex  classifier,  say  the 
number  of  orders  per  month  for  each  month  (e.g.,  this 
would  be  useful  if  the  SSA  only  flew  in  good  weather), 
we  would  have  (possible  food  orders  per  month  * 
possible  fuel  orders  per  month)num^er  months  — 
16777216  possible  rules. 

We  address  this  in  two  separate  cases:  Where  a 
perfect  classifier  exists  in  C,  and  where  one  does  not. 
In  the  first  case,  what  we  are  bounding  is  the  total 
error  (since  there  is  no  approximation  error).  There  is 
a  formula  for  this  that  holds  for  all  5  <  1/2: 

Theorem  1  /7;  6 /.  Let  C  be  a  class  of  discrimination 
functions  with  VC  dimension  V  >2.  Let  X  be  the  set 
of  all  random  variables  ( X ,  Y)  for  which  Lc  =  0.  For 
S  <  1/2  and  e  <  1/2, 

y-i 

*M)>— . 

What  this  comes  down  to  is  the  following.  If  a  per¬ 
fect  classifier  exists,  and  we  have  seen  an  example  to 
which  a  rule  applies,  then  we  will  always  get  that  rule 
right.  If  we  are  asked  to  classify  something  where  the 
training  data  didn’t  contain  a  similar  sample  (similar 
in  the  sense  that  a  rule  left-hand  side  matches),  we 
will  just  be  guessing.  Thus,  as  the  number  of  rules 
(V)  goes  up,  the  sample  size  needed  does  as  well. 

Figure  3  shows  the  minimum  n  needed  for  various 
values  of  e  and  V .  Note  that  the  high  values  of  V  are 

2  Actually  rnnumber  °f  ruie5t  where  m  is  the  number  of  possible 
output  values. 

3For  non-binary,  it  works  out  to  k  s.t.  2fc  =  rnnurnUr  °f 
or  k  =  log2  (mmimbcr  °f  ™le9)  =  number  of  rules  log 2(m). 


Figure  3:  Value  of  n  (vertical  scale)  where  probability 
5  =  1/2  that  there  is  error  e,  as  function  of  error  V 
(left  scale)  and  6  (right  scale),  when  a  perfect  classifier 
is  available. 


likely  to  be  more  relevant  in  practice,  as  it  is  unlikely 
a  perfect  classifier  will  exist  if  the  classifier  is  simple. 

More  interesting  is  what  happens  when  there  isn’t 
a  perfect  classifier  (the  approximation  error  is  greater 
than  0). 

Theorem  2  [7,  6].  LetC  be  a  class  of  discrimination 
functions  with  VC  dimension  V  >  2.  Let  X  be  the 
set  of  all  random  variables  (X,  Y)  for  which  for  fixed 
L  €  (0, 1/2), 


L=infP{5(X)#y}. 


Then  for  every  discrimination  rule  gn  based  on 
Xl,Yl,...,Xn,Yn, 


N(e,5)> 


L(V  -  l)e-10 
32 


x  min 


and  also,  for  e  <  L  <1/4, 

wM>>^io4. 

Note  that  this  gives  us  two  bounds.  One  is  depen¬ 
dent  on  L,  V9  e ,  and  S  (although  for  practical  purposes 
we  would  let  e  =  5  when  using  this);  the  second  is  only 
dependent  on  L,  €,  and  S. 

Some  sample  values  for  the  first,  based  on  e  =  5  = 
.1  (10%  of  being  wrong  at  least  10%  of  the  time)  are 
given  in  Figure  4.  Intuitively,  this  is  based  on  the 
probability  of  choosing  the  wrong  rule  to  use;  this 
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Figure  4:  Value  of  n  (vertical  scale)  below  which  error 
e  >  .1  with  probability  S  >  .1  as  a  function  of  L  (left 
scale)  and  V  (right  scale). 


0.2 


gives  a  sample  size  if  our  primary  concern  is  how  the 
adversary  chooses  a  given  outcome  rather  than  their 
ability  to  predict  the  outcome.  In  other  words,  the 
knowledge  is  in  the  rule,  not  in  the  application  of  the 
rule. 

The  second  formula  is  intuitively  based  on  guessing 
the  wrong  outcome  for  a  given  rule.  Sample  values  are 
given  in  Figures  5  (e  >  0.1)  and  6  (e  >  0.05). 

Note  that  all  of  these  are  rather  small  sample  sizes. 
However,  they  allow  us  to  make  a  strong  statement 
No  matter  how  good  the  adversary’s  data  mining  tech¬ 
nology,  there  are  circumstances  under  which  they  can 
expect  the  results  to  be  poor. 

4.1  Back  to  the  example 

The  figures  given  in  Section  2  are  based  on  Theorem 
1.  This  is  appropriate  for  the  complex  classifier  case 
(a  perfect  classifier  is  likely),  and  due  to  the  huge  VC- 
dimension  (912)  of  such  a  classifier  we  end  up  with  a 
sample  size  N(A,  .5)  =  (912  —  l)/(4  *  .4)  >  175  billion. 

However,  the  simple  classifier  had  a  VC-dimension 
of  6.  This  gives  a  sample  size  of  3  if  a  perfect  classifier 
exists.  Theorem  2  handles  the  case  where  no  perfect 
classifier  exists.  The  first  formula  depends  on  large 
VC-dimension  V  (it  is  really  only  useful  when  V  > 
15, 000).  However,  the  second  form  gives  us  something 
to  work  with.  If  we  start  by  assuming  that  such  a 
simple  classifier  can  be  correct  at  most  75%  of  the 
time  ( L  =  .25),  and  we  want  the  adversary  to  be  forced 
to  accept  an  error  of  10%  (in  other  words,  they  can 
expect  to  be  right  only  65%  of  the  time,  even  though 
they  could  do  as  well  as  75%)  with  probability  5  = 
0.15,  gives  us  our  allowed  sample  of  3  years  of  data. 


0.25 


0.05 


Figure  5:  Value  of  n  (vertical  scale)  below  which  a 
guarantee  of  error  within  0.1  impossible  as  a  function 
of  L  (left  scale)  and  d  (right  scale). 


Figure  6:  Value  of  n  (vertical  scale)  below  which  a 
guarantee  of  error  within  0.01  impossible  as  a  function 
of  L  (left  scale)  and  d  (right  scale). 


Note  that  this  is  the  same  as  the  Lc  —  0  (perfect 
classifier  exists)  case  with  e  ~  0.4  and  5  =  0.5.  This 
seems  strange;  it  appears  easier  to  learn  a  good  clas¬ 
sifier  when  a  perfect  one  doesn’t  exist.  Intuitively,  we 
can  say  that  the  learning  problem  is  harder  if  a  perfect 
answer  exists. 

4.2  Effect  on  a  single  rule 

We  have  determined  what  the  expected  error  is  for 
a  set  of  rules.  The  next  question  is,  what  confidence 
can  the  adversary  have  in  a  single  inference  rule? 

The  preceding  section  gives  an  answer  to  this  ques¬ 
tion.  Since  what  we  have  determined  is  the  probability 
of  the  learned  classifier  failing  to  perform  as  well  as  the 
best  possible  classifier  on  a  given  input ,  it  follows  that 
a  failure  means  that  the  given  rule  gives  the  wrong 
output.  Thus  it  is  the  probability  that  for  any  given 
rule  left-hand  side  (input),  the  output  is  “backwards” 
(since  this  is  a  binary  classifier). 

This,  in  a  sense,  is  a  worst  case  error:  We  have 
a  rule  that  gives  exactly  the  opposite  of  the  proper 
result.  Although  the  probability  of  this  happening 
may  seem  small  (.05  or  .1),  the  result  is  still  significant. 

4.3  Non-binary  outputs 

Another  interesting  situation  is  what  happens  with 
multiple  output  categories.  So  far  we  have  only  dis¬ 
cussed  binary  classifiers;  what  if  their  are  more  than 
two  possible  outcomes? 

A  simple  way  to  model  k  categories  is  as  log2(Ar) 
binary  classifiers  (assuming  the  output  categories  are 
independent).  The  “combined”  classifier  will  fail  if 
any  of  the  binary  classifiers  fail.  Thus  we  can  model 
the  probability  as 

p{fc>  =  p{ki,...,fclog2(fc)} 

=  P{fcl}P{fc2}---P{fc1og2(fc)} 

(as  the  result  “bits”  are  independent). 

=  P{a  binary  classifier  being  correct}1052^ 

This  is  the  probability  of  getting  the  result  correct; 
or  1  —  P{ error}.  Thus,  if  the  expected  error  between 
the  classifier  (or  rule)  learned  on  the  sample  and  the 
correct  rule  is  .1,  the  chance  of  getting  a  rule  right  with 
16  output  categories  is  «  .66.  This  is  the  probability  of 
getting  the  same  result  as  the  best  available  classifier, 
which  is  also  likely  to  have  a  larger  error  than  in  the 
binary  case. 

5  Unintentionally  Released  Data 

A  related  problem  is  what  happens  if  a  sample  is 
released?  In  other  words,  what  if  we  know  the  sample 
size  n?  In  this  case,  the  goal  is  to  determine  “how 
bad”  the  loss  is.  What  we  can  do  is  state  limits  on  the 


probability  that  the  error  is  within  a  given  bound.  In 
other  words,  we  want  to  determine  how  confident  the 
adversary  can  be  in  any  result  mined  from  the  data. 

This  is  similar  to  the  results  in  the  preceding  sec¬ 
tion.  Formally,  the  problem  is  to  find  lower  bounds 
for 

supE L(gn)  -  Lc. 

What  this  states  is  that  there  is  a  distribution  of  the 
data  where  the  adversary  can  expect  they  will  be  off 
by  the  given  amount  with  a  sample  of  size  n  randomly 
chosen  over  that  distribution. 

The  following  theorem  gives  us  a  way  to  make  use 
of  this  information: 

Theorem  3  [13]:  Let  C  be  a  class  of  discrimination 
functions  with  vc  dimension  V.  Let  X  be  the  set 
of  all  random  variables  (X,Y)  for  which  Lc  =  0. 
Then }  for  every  discrimination  rule  gn  based  upon 
XuYu...,Xn,Yn,  andn>V  -  1, 

sup  E Ln  >  ^ — -  (l  -  -)  . 

( x,Y)ex  *en  \  nJ 

This  says  that  if  a  perfect  classifier  exists,  there  is  a 
distribution  of  the  data  such  that  any  classifier  learned 
from  a  random  sample  of  the  data  will  have  at  least 
expected  error  E Ln,  where  this  value  is  dependent  on 
the  vc-dimension  V  and  the  sample  size  n. 

Since  this  function  is  continually  decreasing  for  n  > 
2,  it  gives  the  maximum  at  the  lower  limit  where  the 
theorem  applies:  n  —  V  —  1.  At  this  point  the  upper 
bound  is 

—^(1  —  ~)  >  0.18  when  V  >  50. 

This  means  that  given  a  sample  of  size  n  <  V  —  1,  it 
is  possible  that  any  classifier  learned  from  the  sample 
will  be  wrong  18%  of  the  time  (there  exists  a  distri¬ 
bution  of  the  data  such  that  this  will  hold). 

There  are  similar  theorem  for  the  case  V  >  0,  but 
they  only  apply  for  large  n,  where  the  expected  error 
is  so  small  as  to  be  nearly  useless  (less  than  1%). 

6  Conclusions  and  Further  Work 

Pattern  recognition  theory  gives  us  tools  to  deal 
with  security  and  privacy  issues  in  data  mining.  Lim¬ 
iting  the  sample  size  that  can  be  mined  allows  us  to 
state  clear  limits  on  what  can  be  learned  from  the 
sample.  These  limits  are  in  the  form  of  expected  error 
on  what  is  learned.  What  they  allow  us  to  do  is  tell 
an  adversary,  “Here  is  a  sample  you  may  mine,  but 
you  can  expect  any  result  you  get  will  be  wrong  e%  of 
the  time  with  probability  5 ,  no  matter  how  good  your 
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data  mining  is”.  It  gives  us  sample  sizes  where  we  can 
expect  that  the  sample  may  be  misleading. 

One  advantage  of  this  approach  is  that  the  method 
can  be  open.  The  adversary  cannot  use  knowledge  of 
how  we  restrict  sample  size  to  improve  the  data  min¬ 
ing  process.  In  fact,  the  knowledge  that  results  from 
mining  the  sample  cannot  be  trusted  may  discourage 
the  adversary  from  making  the  attempt. 

These  sample  sizes  tend  to  be  small  (10s  or  100s  of 
tuples).  However,  for  certain  purposes  this  is  reason¬ 
able.  For  example,  providing  samples  of  actual  data 
to  be  used  for  development  of  new  systems  to  operate 
in  a  secured  environment.  These  formulas  give  us  the 
ability  to  state  “this  is  a  safe  amount  of  data  to  re¬ 
lease”  ,  without  worrying  about  the  specific  inferences 
that  may  be  drawn.  This  is  independent  of  the  exter¬ 
nal  knowledge  available  to  the  adversary  (except  for 
the  database  contents  not  included  in  the  sample). 

Another  thing  we  gain  is  the  ability  to  analyze  the 
effect  of  a  given  sample  size.  This  is  useful  when  data 
is  released  unintentionally;  we  can  analyze  the  poten¬ 
tial  impact  of  the  release  both  in  terms  of  the  direct 
inferences  that  can  be  made,  and  the  “probabilistic 
inferences”  that  can  be  determined  by  data  mining. 
Again,  this  is  independent  of  the  technology  or  exter¬ 
nal  knowledge  available  to  the  adversary. 

There  are  various  ways  we  can  extend  this  work. 
One  is  in  the  realm  of  support  to  a  data  security  ad¬ 
ministrator;  an  “operations  manual”  for  determining 
how  much  data  to  release.  The  primary  effort  required 
is  determining  appropriate  parameters  for  a  classifier. 
One  solution  would  be  to  use  clustering  techniques 
on  the  database  (e.g.,  self-organizing  maps  [10]  with 
thresholds  on  nearest  neighbor)  to  give  a  likely  value 
for  the  vc-dimension  of  a  reasonable  classifier.  This 
idea  is  based  on  grouping  the  potential  rule  left-hand 
sides  into  similar  groups,  with  the  idea  that  similar  in¬ 
puts  would  likely  lead  to  similar  outputs.  A  classifier 
on  extremely  diverse  data  is  likely  to  be  more  com¬ 
plex  than  one  on  simple  data.  This  needs  more  work 
to  establish  limits  on  the  probabilities  involved. 

Another  area  for  extension  is  that  this  work  as¬ 
sumes  the  sample  obtained  by  the  adversary  is  ran¬ 
domly  distributed.  However,  many  applications  will 
produce  non-random  samples.  An  example  of  this 
would  be  a  system  that  allows  queries  to  a  database 
(access  to  individual  information),  but  tries  to  protect 
correlations  among  items  through  limiting  the  volume 
of  data  available.  In  such  a  system  the  adversary  con¬ 
trols  the  sample  distribution.  What  can  we  say  about 
such  an  environment? 

There  are  a  number  of  possibilities: 


•  The  sample  is  random  with  respect  to  a  correla¬ 
tion  discovered.  In  this  case,  the  fact  that  the 
sample  is  not  random  with  respect  to  some  crite¬ 
ria  is  irrelevant. 

•  A  discovered  correlation  involves  the  selection  cri¬ 
teria.  The  problem  is  that  we  cannot  say  if  the 
correlation  is  unique  to  the  selection  criteria:  It 
may  or  may  not  be  independent  of  the  selection 
criteria. 

•  A  correlation  exists  between  the  selection  crite¬ 
ria  and  some  other  field  in  the  data.  The  previ¬ 
ous  case  prevents  our  discovering  this  correlation, 
however  does  the  non-randomness  of  the  sample 
allow  us  to  discover  other  correlations  between 
the  “other  field”  and  other  items?  Or  does  this 
reduce  to  the  previous  case? 

•  The  adversary  has  multiple  samples  based  on  dif¬ 
ferent  selection  criteria.  One  obvious  sub-case 
of  this  is  a  random  sample  and  a  non-random 
sample.  Does  this  allow  us  to  discover  correla¬ 
tions  with  respect  to  the  selection  criteria  that  we 
would  not  expect  to  discover  with  a  random  sam¬ 
ple?  As  a  worst  case,  this  would  give  us  the  effect 
of  a  sample  size  as  large  as  the  size  of  a  random 
sample  required  to  give  all  the  selected  items.  As 
a  best  case,  this  would  appear  as  a  random  sam¬ 
ple.  The  actual  bound  is  probably  somewhere  in 
the  middle  -  this  needs  to  be  worked  out. 

This  is  related  to  work  in  privacy  problems  from 
data  aggregation  [3,  1].  The  statistical  database  in¬ 
ference  problem  deals  with  identifying  individual  data 
values  from  one  or  more  summary  queries.  In  a  sense 
it  is  the  converse  of  the  problem  of  this  paper;  instead 
of  protecting  against  learning  data  items  from  aggre¬ 
gates,  we  are  protecting  against  learning  aggregates 
from  individual  items.  Although  the  basic  problem  is 
quite  different,  as  we  move  toward  non-random  sam¬ 
ples  the  two  areas  may  overlap.  Of  particular  note  is 
work  on  random  sampling  queries  [5];  this  may  provide 
tools  to  implement  policies  governing  the  creation  of 
non-random  samples. 

Another  possible  starting  point  for  this  is  artificial 
intelligence  work  on  selection  of  training  data  [2,  15]. 
Preventing  the  adversary  from  selecting  a  “good”  set 
of  training  data  (while  still  allowing  some  queries,  and 
those  non-random  release  of  data)  would  support  this 
work. 

Another  area  is  the  effect  on  correlations,  rather 
than  inference  rules.  The  example  in  Section  2  was 
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based  on  developing  a  classifier  to  predict  based  sup¬ 
porting  the  SSA.  Alternatively,  the  correlation  be¬ 
tween  “lots  of  fuel”  and  “SSA”  may  be  of  interest.  The 
problem  is  similar,  however  understanding  the  effect  of 
small  samples  on  the  significance  of  such  correlations 
(e.g.,  chi-squared  measures)  is  still  open. 

What  we  have  shown  is  that  for  reasonably  small 
samples,  we  can  be  confident  that  the  threat  posed  by 
data  mining  is  minor. 

References 

[1]  Sumit  Dutta  Chowdhury,  George  T.  Duncan,  Ra- 
mayya  Krishnan,  Stephen  Roehrig,  and  Sumi- 
tra  Mukherjee.  Logical  vs.  numerical  inference 
on  statistical  databases.  In  Proceedings  of  the 
Twenty-Ninth  Hawaii  International  Conference 
on  System  Sciences ,  pages  3-10,  January  3-6 
1996. 

[2]  Dawn  M.  Cohen,  Casimir  Kulikowski,  and  Helen 
Berman.  DEXTER:  A  system  that  experiments 
with  choices  of  training  data  using  expert  knowl¬ 
edge  in  the  domain  of  DNA  hydration.  Machine 
Learning ,  21:81-101,  1995. 

[3]  Lawrence  H.  Cox.  Protecting  confidentiality  in 
small  population  health  and  environmental  statis¬ 
tics.  Statistics  in  Medicine ,  15:1895-1905,  1996. 

[4]  Harry  S.  Delugach  and  Thomas  H.  Hinke.  Wiz¬ 
ard:  A  database  inference  analysis  and  detection 
system.  IEEE  Transactions  on  Knowledge  and 
Data  Engineering ,  8(1),  February  1996. 

[5]  Dorothy  E.  Denning.  Secure  statistical  databases 
with  random  sample  queries.  ACM  Transactions 
on  Database  Systems ,  5(3):291-315,  September 
1980. 

[6]  Luc  Devroye,  Laszlo  Gyorfi,  and  Gabor  Lugosi. 
A  Probabilistic  Theory  of  Pattern  Recognition. 
Springer- Verlag,  New  York,  1996. 

[7]  Luc  Devroye  and  Gabor  Lugosi.  Lower  bounds  in 
pattern  recognition  and  learning.  Pattern  Recog¬ 
nition ,  28:1011-1018,  1995. 

[8]  Thomas  H.  Hinke  and  Harry  S.  Delugach.  Aerie: 
An  inference  modeling  and  detection  approach  for 
databases.  In  Bhavani  Thuraisingham  and  Carl 
Landwehr,  editors,  Database  Security ,  VI,  Status 
and  Prospects:  Proceedings  of  the  IFIP  WG  11.3 
Workshop  on  Database  Security ,  pages  179-193, 
Vancouver,  Canada,  August  19-21  1992.  IFIP,  El¬ 
sevier  Science  Publishers  B.V.  (North-Holland). 


[9]  Thomas  H.  Hinke,  Harry  S.  Delugach,  and  Ran¬ 
dall  P.  Wolf.  Protecting  databases  from  inference 
attacks.  Computers  and  Security ,  16(8)  :687— 708, 
1997. 

[10]  Teuvo  Kohonen.  The  self  organizing  map.  IEEE 
Transactions  on  Computers ,  78(9):1464-1480, 
1990. 

[11]  Donald  G.  Marks.  Inference  in  MLS  database 
systems.  IEEE  Transactions  on  Knowledge  and 
Data  Engineering ,  8(1),  February  1996. 

[12]  C.  Stone.  Consistent  nonparametric  regression. 
Annals  of  Statistics,  (8):1348-1360,  1977. 

[13]  V.  Vapnik  and  A.  Chervonenkis.  Theory  of  pat¬ 
tern  recognition,  1974.  (in  Russian). 

[14]  Vladimir  Naumovich  Vapnik.  Estimation  of  de¬ 
pendences  based  on  empirical  data.  Springer- 
Verlag,  New  York,  1982. 

[15]  Jihoon  Yang  and  Vasant  Honavar.  Feature 
subset  selection  using  a  genetic  algorithm. 
IEEE  INTELLIGENT  SYSTEMS ,  13(2):44-49, 
March/April  1998. 

[16]  R.  Yip  and  K.  Levitt.  The  design  and  implemen¬ 
tation  of  a  data  level  database  inference  detec¬ 
tion  system.  In  Proceedings  of  the  Twelfth  Annual 
IFIP  WG  11.3  Working  Conference  on  Database 
Security ,  July  15-17  1998. 


167 


168 


Security  Administration  for  Federations,  Warehouses,  and  other 

Derived  Data 

Amon  Rosenthal,  Edward  Sciore,  Vinti  Doshi1 

Abstract 

Security  administration  is  harder  in  databases  that  have  multiple  tiers  of  derived  data,  such  as 
federations,  warehouses,  or  systems  with  many  views.  Metadata  (e.g.,  security  requirements) 
expressed  at  each  tier  must  be  visible  and  understood  at  the  other  tier.  We  describe  several  use 
cases  in  which  tiers  negotiate  to  reconcile  their  business  requirements.  The  sources  must  grant 
enough  privileges  for  the  derived  tier  to  support  the  applications;  the  derived  tier  must  enforce 
enough  restrictions  so  that  the  sources’  concerns  are  met;  and  the  relationship  between  the 
privileges  at  source  and  derived  tier  must  be  visible  and  auditable. 

The  guiding  principle  is  that  a  security  policy  should  primarily  govern  information-,  controls  over 
source  tables  and  views  from  which  the  information  can  be  obtained  are  intended  to  implement 
such  policies.  We  require  a  kind  of  global  consistency  of  policy,  based  on  what  information 
owners  assert  about  tables  and  views.  Deviations  are  primarily  a  local  affair,  and  must  occur 
within  safe  bounds.  Our  theory  examines  view  definitions,  and  includes  query  rewrite  rules, 
differing  granularities,  and  permissions  granted  on  views.  Finally,  we  identify  open  problems  for 
researchers  and  tool  vendors. 


1  Introduction 

Federations  and  warehouses  [Osz,  Inm]  are  examples  of  multi-tier  database  systems.  Data 
originates  in  a  source  tier.  The  derived  tier  consists  of  information  derived  from  the  sources.  The 
system  should  have  an  integrated  security  policy,  so  that  each  granule  of  data  is  protected 
consistently,  whether  obtained  through  the  source  or  derived  tier.  Creating  such  a  policy  requires 
negotiations  between  administrators  at  different  tiers. 

The  goal  of  this  paper  is  to  alert  the  security  community  to  the  administration  problems  in  such 
multi-tier  systems,  and  to  suggest  a  model  within  which  the  necessary  research  can  be  done.  We 
present  motivating  scenarios,  and  give  initial  sketches  of  the  necessary  theory,  methodologies  and 
automated  tool  support.  The  metadata  management  problem  for  warehouses  and  federations  is 
broad  and  murky.  Our  main  contribution  is  to  formulate  a  problem  that  can  be  fruitfully  addressed 
both  by  tool  vendors  and  by  researchers. 

1.1  The  Need  for  Collaboration 

The  tiers  in  a  multi-tier  database  are  often  administered  separately,  which  makes  security 
administration  harder  than  in  a  centralized  system.  Administrative  activities  at  one  tier  may  affect 
other  tiers,  and  thus  need  to  be  visible  and  understood  at  these  tiers.  For  example,  if  a  source  tier 
grants  or  revokes  the  access  permissions  on  one  of  its  tables,  it  must  communicate  this  to  derived 


1  Addresses:  A.  Rosenthal,  V.  Doshi,  The  MITRE  Corporation  {amie,  vdoshi)  @mi  tre.org. 
E.  Sciore,  Boston  College  (and  MITRE)  sciore@bc.edu. 
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tiers  that  use  that  table.2  Similarly,  if  a  derived  tier  wishes  to  give  a  particular  subject  (e.g.,  user, 
role,  group)  access  to  one  of  its  tables,  it  must  request  permission  from  the  (source  tier)  owners  of 
information  used  to  derived  the  table,  in  terms  of  each  owner’s  schemas. 

The  administrators  of  each  tier  must  be  able  to  negotiate  with  each  other,  in  order  to  match 
security  and  business  requirements.  In  particular,  negotiation  aims  at: 

*  Protecting  information,  as  its  owners  require. 

*  Giving  sufficient  access  permissions  so  applications  can  accomplish  their  tasks. 

*  Enforcing  the  agreed-upon  access  policies  as  efficiently  and  reliably  as  possible. 

*  Allowing  administrators  at  different  tiers  to  understand  each  other’s  concerns,  without 
needing  to  understand  each  other’s  schema  and  the  derivation  logic. 

1.2  Source  versus  Derived  Permissions 

Administrators  need  to  see  all  relevant  security  metadata,  whether  initially  provided  in  terms  of 
their  “native”  schema  or  a  foreign  schema.  To  enable  this  visibility,  negotiation  support  must 
include  a  translation  step.  We  sketch  the  theory  here,  and  revisit  in  more  detail  in  section  3. 

Current  multi-tier  systems  do  not  really  connect  the  source-tier  and  derived-tier  permissions.  For 
example  in  a  federation,  a  middleware  product  (as  the  owner  of  federation  views)  may  be  given 
unlimited  Read  access  to  sources,  with  Grant  option.  This  approach  places  great  burdens  and  trust 
on  the  federation  administrator,  but  provides  neither  guidance  nor  tools.  In  particular,  there  is  no 
formal  basis  for  source  administrators  to  judge  whether  the  permissions  that  the  federation 
administrator  grants  are  appropriate. 

Our  approach  is  based  on  three  premises: 

1.  Ownership  and  access  controls  are  fundamentally  about  information,  not  physical  artifacts 
(source  tables)  or  interfaces  (views).  That  is,  protection  must  be  global.  This  implies  that 
access  controls  asserted  at  one  schema  must  be  propagated  to  the  other  schemas. 

2.  A  table’s  permissions  are  the  sum  of  two  sources:  permissions  explicitly  asserted  on  the  table, 
plus  permissions  inferred  from  permissions  on  other  tables.  If  you  have  Read  permission  on 
tables  X  and  Y,  you  get  permission  on  any  view  you  can  compute  from  X  and  Y. 

Conversely,  one  gets  read  permission  for  a  view  V  if  there  is  any  query  that  computes  V  from 
tables  to  which  you  have  access. 

3.  Administrators  of  implementation  units  (source  tables,  views,  replicas)  may  reduce  the 
permissions  allowed  by  (2),  but  not  expand  them.  These  restrictions  often  stem  from  a  desire 
to  control  physical  resources.  To  protect  response  times  or  generate  revenues,  one  database 
might  access  only  by  known  subscribers.  To  reduce  hacker  threats,  another  might  allow 
access  only  by  the  enterprise’s  employees. 

These  premises  guarantee  that  the  access  permissions  in  a  database  are  consistent.  That  is,  if  a 
user  has  access  to  information  in  one  part  of  the  database,  the  user  has  access  to  that  information 
everywhere  in  the  database.  Section  3.6  discusses  a  mechanism  for  superimposing  local 
restrictions. 


2  Henceforth,  we  shall  use  the  terms  “view”  and  “derived  table”  interchangeably,  allowing  virtual  and 
materialized  derived  tables,  which  need  not  be  perfectly  consistent.  ‘Table”  comprises  both  source  tables 
and  views. 
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1.3  Assumptions  and  Simplifications 


Our  work  does  not  address  the  usual  problems  of  integrating  distributed  heterogeneous  data,  nor 
deal  with  all  aspects  of  security  for  an  enterprise  database.  We  assume  that  a  metadata 
management  environment  (denoted  MME),  provides  the  illusion  of  several  kinds  of  uniformity: 

*  Schemas,  metadata,  and  distributed  databases:  The  source  and  view  schemas  and  their 
metadata  are  represented  in  a  repository.  All  schemas  and  views  are  in  the  same  language 
(e  g-,  SQL). 

*  Permission  types:  MME  defines  a  uniform  set  of  permission  types  (e.g..  Create,  Read, 
Update,  Delete),  across  all  tiers. 

*  Subjects  to  whom  privileges  are  granted:  MME  manages  grants  of  access  permissions  to 
subjects  (e.g.,  users  or  roles)  that  are  globally  known  across  tiers.  Authentication, 
management  of  role  membership,  and  subject  globalization  (i.e.,  specifying  which  global 
subject  corresponds  to  each  DBMS  or  operating  system  subject)  are  outside  our  scope. 

Some  further  assumptions  simplify  our  prose.  We  believe  that  each  of  them  could  easily  be 
removed,  as  indicated: 

*  We  speak  in  terms  of  only  two  tiers  -  a  source  tier  and  a  derived  tier  -  so  each  administrator 
sees  just  one  “foreign”  tier.  (Actually,  the  derivation  graph  can  be  arbitrary.) 

*  We  assume  that  view  definitions  are  readable  by  all  users(rather  than  allow  them  to  be 
protected  objects). 

*  We  ignore  delays  in  propagating  data  and  metadata  updates. 

*  We  do  not  model  Grants  of  Grant  authority.  Instead,  we  merely  speak  of  owners  of 
information.  An  owner  can  work  in  terms  of  source  tables  (the  usual  case)  or  view  tabled 
(e.g.,  if  the  sources  are  merely  an  efficient  physical  representation  of  a  natural  conceptual 
table). 

Federations  and  warehouses  bring  together  a  great  deal  of  information,  increasing  the 
aggregation  vulnerabilities:  Information  that  in  isolation  was  not  sensitive  can  become  sensitive 
when  made  accessible  together,  e.g.,  via  a  federation  [Jaj,  Thu].  However,  the  proposed  solutions 
to  this  problem  for  centralized  systems  seem  to  provide  modest  extra  security,  at  very  high  cost  in 
run-time  and  administration  (e.g.,  quadratic  growth).  We  therefore  do  not  address  this  issue. 

1.4  Paper  Roadmap 

Section  2  covers  the  kinds  of  negotiation  that  are  possible  between  the  source  and  derived  tiers.  In 
it,  we  show  that  communication  can  be  split  into  a  requested  action  and  a  translation  of 
permissions  from  one  schema  to  another.  Section  3  examines  the  underlying  theory  that  allows 


3  To  become  owner  of  a  view,  one  must  somehow  receive  authorization  ffom  owners  of  all  information 
used  in  forming  the  view.  Mechanisms  for  such  collaborative  delegation  are  a  subject  for  future  research. 
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this  translation  to  proceed.  Section  4  discusses  conclusions  and  suggests  promising  open  research 
problems. 

2  Negotiation  Scenarios 

The  tiers  in  a  multi-tier  database  may  be  administered  separately,  with  conflicting  goals. 

This  section  illustrates  the  kinds  of  negotiations  that  must  be  performed,  and  implicitly  the  kinds 
of  capabilities  a  metadata  coordination  tool  must  provide.  Its  research  contribution  is  to  identify, 
from  the  overwhelming  set  of  real  requirements,  scenarios  that  point  at  useful,  feasible  facilities 
for  permission  negotiation  and  translation.  In  particular,  we  try  to  answer: 

*  What  sort  of  negotiations  do  the  tiers  ’  administrators  need  to  perform ? 

*  What  sorts  of  requests  do  they  need  to  send  to  each  other?  There  appear  to  be  a  mix  of 
commands,  proposals,  notifications,  and  comparisons. 

*  How  are  requests  for  permissions  translated  to  the  recipients  ’  schemas ?  Each  party  needs 
to  know  what  has  been  said,  in  terms  of  its  own  schema. 

Many  tasks  involve  a  set  of  permissions  against  the  requestor’s  schema,  a  target  schema,  a 
recipient  for  the  permissions  (translated  to  refer  to  the  target  schema),  and  a  desired  action.  The 
action4  may  be  a  command  to  install  the  translated  permissions  (“Enforce  these  permissions  at 
your  tier.”),  a  proposal  (“I  would  like  you  to  cause  these  permissions  to  be  true.”),  a  description 
of  what  the  tier  is  doing  (“For  your  information:  Here  are  the  permissions  I  enforce.”),  or  a 
hypothetical  display  (“If  I  granted  these  permissions,  how  would  it  look  on  the  target  schema?”) 

The  scenarios  below  present  more  detail.  The  following  2-tier  Hospital  database  provides  a 
running  example.  The  source  tier  contains  the  two  base  tables: 

PATIENT  (Patientld,  Insurance_Co) 

PROCEDURE  (Patient_Id,  Procedure_Performed,  Doctor,  Bill_Amount,  Date) 

The  view  tier  contains  the  derived  tables: 

DOCTOR_ACTIVITY  (Doctor,  Procedure_Performed,  Month,  Year) 

INSURANCE  (Insurance_Co,  Month,  Year,  Total_Billed) 

The  first  view  is  a  selection  from  PROCEDURE;  the  second  joins  PATIENT  and  PROCEDURE, 
and  then  groups  by  Insurance_Co  and  (Month,  Year)  from  Date,  and  totals  the  Bill_Amount. 

2.1  Bottom-Up:  Conforming  to  implied  permissions 

In  the  first  scenario,  the  view  tier  is  a  data  warehouse  over  the  Hospital  database.  Derived  tables 
are  materialized  views,  whose  derivation  may  involve  complex  fusion  and  scrubbing  logic.  The 
warehouse  handles  user  requests  without  referring  back  to  sources,  and  hence  checks  all 
permissions  itself.  The  warehouse’s  permissions  should  conform  to  the  source’s  intentions. 

The  source  tier  keeps  the  warehouse  informed  about  what  access  permissions  to  enforce. 
Whenever  a  grant  or  revoke  command  occurs  at  the  source,  the  metadata  management 
environment  transmits  the  command  to  the  warehouse,  and  translates  the  source’s  command  to  an 
appropriate  action  on  the  appropriate  view  tables.  For  example,  a  grant  on  PROCEDURE 


4  These  actions  are  themselves  subject  to  permissions.  A  table  owner  may  impose  limits  on  who  can  enter 
requests  that  the  responsible  dba  sees,  and  drastically  limit  those  who  can  automatically  install  permissions. 
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translates  to  a  grant  on  DOCTOR_ACTIVITY  and,  if  there  is  an  existing  corresponding  grant  on 
PATIENT,  a  grant  on  INSURANCE. 

Automated  translation  is  crucial,  both  to  reduce  administrator  workload  and  to  keep  the  system 
secure  in  a  dynamic  environment.  When  a  source  revokes  a  permission,  the  warehouse  should 
immediately  reflect  the  revocation.  A  message  expressed  in  terms  of  source  tables  will  be 
unintelligible  to  installer  scripts  at  the  warehouse  DBMS.  Even  human  administrators  will  react 
slowly  and  unreliably  when  presented  with  changes  in  terms  of  another  tier’s  tables. 

In  the  second  scenario,  the  derived  tier  is  a  federated  database.  Permissions  are  asserted  against 
source  schemas,  and  enforcement  occurs  after  the  user’s  query  is  translated  to  a  query  on  source 
tables.  The  system  can  execute  without  translating  permissions  to  refer  to  derived  tables.  But 
derived  tier  users  want  to  use  their  own  tables  when  inspecting  the  permissions  that  they  possess, 
or  when  they  have  been  refused  access.  Consequently,  the  source  administrator  should  transmit 
grant  and  revoke  permissions  to  the  derived  tier,  as  in  scenario  1. 

In  the  general  case,  some  views  may  be  derivable  from  other  views.  In  such  cases,  permissions  on 
the  lower  views  will  also  need  to  propagate  upward. 

Our  example  views  are  simpler  than  the  general  case,  but  we  believe  such  simplicity  occurs  often 
in  real  life.  Even  complex  derivations  often  return  some  attributes  that  were  simply  pulled  from 
source  tables.  For  the  remaining  cases,  we  contend  that  an  administrator’s  assistant  need  not  be 
complete  to  be  useful.  In  fact,  it  may  be  very  helpful  for  researchers  to  point  out  and  formalize 
easy  cases,  where  there  can  be  substantial  benefit  at  little  cost. 

2.2  Top-Down:  Proposing  new  permissions 

This  scenario  applies  to  either  the  warehouse  or  federation  examples  above.  Suppose  the  derived 
tier  administrator  proposes  an  increase  in  her  users’  permissions.  For  example,  suppose  cost 
analysts  need  to  be  able  to  read  the  INSURANCE  table.  The  derived  tier  administrator  sends  a 
message  to  the  source  tier  requesting  this  change. 

The  system  executes  this  message  as  follows.  The  first  step  is  to  compare  the  desired  and  existing 
permissions  on  the  derived  tables,  so  that  only  the  additional  (delta)  permissions  will  be 
requested.  There  should  be  less  work  in  judging  the  delta,  and  we  avoid  redundant  grants  that 
invite  confusion  when  privileges  are  revoked.  In  the  example,  suppose  costAnalyst  already  has 
access  to  PROCEDURE,  and  requests  access  to  view  INSURANCE.  When  the  request  is 
translated  to  the  sources,  one  would  ask  for  a  new  Grant  only  on  PATIENT.  In  systems  with 
column  permissions,  one  might  determine  that  Analyst  already  had  permission  to  read  the  first 
three  INSURANCE  columns,  so  the  downward  translation  consists  of  a  request  for  access  only  to 
INSURANCE.Billed_Amount. 

At  this  point,  the  source  administrator  has  several  options.  If  she  is  willing  to  make  the  change, 
agreement  has  been  reached.  Or  she  may  instead  make  a  counterproposal.  The  counteroffer  is 
translated  in  “bottom-up”  mode  to  the  derived  tier  administrator,  who  again  may  agree,  or 
continue  the  negotiation. 

A  counterproposal  may  take  several  forms.  The  administrator  may  propose  a  different  user  (e.g. 
“costAnalystSupervisor”)  be  assigned  the  desired  permissions.  Or  the  two  administrators  might 
jointly  determine  that  a  new  user  role  is  required. 
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Alternatively,  the  administrator  may  propose  to  create  one  or  more  views  that  are  useful  in 
answering  derived  tier  queries,  but  are  less  sensitive  than  the  underlying  tables  [Sto75].  For 
example,  given  a  request  for  cost  analyst  access  to  the  PATIENT  table,  the  source  administrator 
may  counter-propose  that  cost  analysts  be  given  access  to  a  view  that  contains  only  those  patients 
who  were  seen  this  year.  Or  the  source  administrator,  feeling  that  Patient_Id  values  must  be  kept 
confidential,  gives  analysts  access  to  a  view  that  is  the  join  of  PATIENT  and  PROCEDURE, 
projecting  out  the  Patient_Id.  The  view  query  for  INSURANCE  can  be  rewritten  to  employ  that 
view  instead.5 

Finally,  we  note  that  it  may  be  useful  for  the  source  to  grant  a  wider  set  of  permissions  than  were 
requested.  For  example,  suppose  the  derived  tier  administrator  requests  that  cost  analysts  be 
given  access  to: 

Select  Procedure_Performed,  Bill_Amount 
From  PATIENT 
Where  Year  >  1996 

The  source  administrator  determines  that  this  information  is  suitable  for  cost  analysts  to  see,  and 
therefore  is  willing  to  create  a  view  for  it.  However,  the  administrator  realizes  that  other  fields  are 
equally  releasable  (e.g.,  Doctor,  Date),  as  are  pre-1996  records.  Furthermore,  it  is  likely  that  cost 
analysts  will  later  want  to  see  other  fields  or  selection  criteria.  Hence,  the  source  administrator 
chooses  to  define  and  grant  Read  access  to  the  following  wider  view: 

Select  Procedure_Performed,  Bill_Amount,  Doctor,  Date 
From  PATIENT 

Expanding  the  view  contravenes  the  principle  of  least  privilege,  but  may  reduce  the 
administrator’s  workload  substantially. 

In  the  above  scenarios,  the  source  had  ultimate  control  over  permissions.  Our  approach  also 
accommodates  scenarios  where  the  security  officer  works  in  terms  of  the  view  schema.  For 
example,  often  a  conceptual  object  (e.g.,  HOSPITAL)  is  partitioned  and  denormalized  for 
efficiency,  and  expressed  as  a  view.  The  physical  tables  represent  no  natural  application  unit.  For 
administering  information  security,  the  HOSPITAL  view  may  be  a  more  natural  venue.. 

2.3  Comparison:  Check  the  consistency  of  the  two  tiers 

If  all  tiers  faithfully  imposed  the  information  owners’  permissions,  the  permissions  would  all  be 
consistent.  This  is  not  how  systems  are  administered  today.  For  example,  suppose  information 
owners  use  just  the  source  schema  to  express  permissions,  and  consider  a  warehouse  that  enforces 
permissions  on  queries  against  the  (derived)  warehouse  schema.  Auditors  may  want  to  check 
whether  all  permissions  granted  on  the  warehouse  can  be  inferred  from  the  source  permissions.  If 
not,  there  may  be  a  serious  security  violation.  Today,  such  checks  are  so  troublesome  that  they 
are  rarely  done.  With  automated  comparisons,  one  could  do  a  nightly  consistency  check  on 
critical  information. 

All  of  these  comparisons  require  that  permissions  be  expressed  in  terms  of  the  same  schema.  One 
can  translate  source  permissions  upward,  to  refer  to  the  derived  schema.  These  are  easily 
compared  with  the  permissions  actually  granted  by  a  warehouse.  The  resulting  exception  report 
identifies  both  warehouse  permissions  that  were  not  justified  by  sources,  and  source  permissions 


5  The  view  need  not  be  rewritten  if  the  system  takes  advantage  of  query  equivalence,  as  discussed  in 
Section  3.5. 
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that  the  warehouse  has  chosen  not  to  grant.  If  desired,  the  exception  report  can  be  treated  as  a 
proposal,  to  be  propagated  downward  (as  discussed  in  section  2.2). 

2.4  Pointers  to  Additional  Material 

A  mockup  demonstration  of  elementary  negotiation  and  translation  is  available  on  the  web  pages 
[Ros99b].  An  interface  mockup  shows  administrators  communicating  proposed  metadata  changes 
upwards  and  downwards.  It  also  shows  the  rules  for  translating  permissions  (and  some  other 
kinds  of  metadata)  to  refer  to  the  other  tier’s  schema,  and  the  management  of  these  translation 
rules.  A  paper  describing  more  sophisticated  negotiation  support  is  also  available  there. 
Frameworks  for  building  and  extending  such  tools  are  discussed  in  [Ros98,  Ros99a]. 


3  Handling  Access  Control  Metadata 

The  scenarios  above  illustrated  database  administrator’s  requirements  in  a  multi-tier  database, 
especially  for  negotiations.  This  section  focuses  on  the  model  of  permissions,  and  their  translation 
(i.e.,  inference)  across  tiers.  To  encourage  vendors  to  move  the  results  into  product,  we  seek 
broad  applicability  but  simple  implementation. 

3.1  Preliminaries 

Access  permissions  are  associated  with  source  or  view  tables  in  a  schema.  There  are  two  popular 
ways  of  representing  a  table’s  access  permissions:  as  a  set  of  Access  Control  Lists  (i.e.,  {subjects 
with  a  given  permission}),  or  as  a  single  access  predicate.  A  predicate  formalism  is  more  flexible 
(it  lets  us  include  other  tests,  e.g.,  on  time-of-day  or  user’s  department)  and  has  a  solid  base  in 
logic.  The  ACL  notation  is  more  intuitive  for  Granting  and  Revoking.  We  use  access  predicates, 
but  the  same  results  hold  for  ACLs. 

Formally,  the  expression  Allow(T,  p)  denotes  that  if  predicate  p  is  satisfied,  one  can  access  table 
T6.  A  table  can  have  any  number  of  such  access  permissions  with  “OR”  semantics,  e.g.,  from 
separate  SQL  Grant  operations. 

We  separate  a  table’s  permissions  into 

*  Information  permissions:  Here,  the  information’s  owner  wishes  to  impose  controls  on  all 
routes  through  which  a  particular  kind  of  information  (e.g.,  patients’  names)  can  be  accessed. 
From  this  information  policy,  one  derives  permissions  to  be  allowed  on  each  table. 

*  Physical  resource  permissions:  Permissions  that  are  associated  with  concrete  processing 
resources  (e.g.,  physical  tables,  interfaces  with  executable  code).  These  allow  administrators 
to  deal  with  local  requirements  for  system  security,  performance,  or  payment. 

To  access  information  from  a  table,  one  needs  both  the  information  and  the  physical  resource 
permissions.  Administrators  working  with  derived  tables  will  need  answers  about  both,  e.g.,  “Are 
cost-analysts  allowed  to  read  patient  names”  and  “Will  some  system  that  possesses  patient  names 
allow  me  to  run  my  queries?”  The  two  properties  are  likely  to  be  administered  separately. 
Information  permissions  are  discussed  in  sections  3. 1-3 .4,  and  physical  resources  in  3.5. 


6  To  simplify  notation,  we  omit  “subject”  and  “operation”  as  explicit  arguments.  Until  the  last  part  of 
section  3.2,  our  examples  focus  on  Read. 
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3.2  Inferring  Access  Permissions 

Given  a  (base  or  derived)  table  T,  the  following  rules  define  the  inferred  permissions  associated 
with  T. 


All_perms(T) 

Direct_perms(T) 

Inferred_perms(T) 

Query_perms(T,Q) 


=  OR{  Direct_perms(T),  Inferred_perms(T) } 

=  OR{  p  |  Allow(T,  p)  was  asserted  } 

=  OR{  Query_perms(T,Qi)  |  T  can  be  computed  by  query  Qi } 
=  AND{  All_perms  (Ti)  |  query  Q  mentions  table  Ti } 


The  first  two  rules  are  straightforward.  The  first  rule  states  that  a  permission  on  T  can  be  either 
directly  asserted  or  inferred.  The  second  rule  formalizes  the  idea  (from  section  3.1)  that  the 
meaning  of  multiple  direct  assertions  is  the  same  as  the  OR  of  the  individual  predicates. 

The  last  two  rules  go  together,  to  say  that  you  get  access  permission  on  a  table  T  if  you  have 
(direct  or  inferred)  permission  on  all  tables  mentioned  by  some  query  that  calculates  T.  To 
illustrate,  consider  a  typical  case  of  inferring  permissions  on  a  view  table  V  defined  by  query 
Q(Tl,...,Tk).  Then  V  (by  definition)  can  be  computed  by  Q.  Assuming  no  other  query  computes 
V,  the  rules  state  that 

Inferred__perms(V)  =  AND{All_perms(Tl),...,All_perms(Tk)}. 

In  other  words,  anyone  who  has  access  permissions  on  Q  can  be  inferred  to  have  the  same 
permissions  on  V. 

One  might  also  infer  permissions  on  base  tables.  For  example,  consider  the  base  table 
PROCEDURE  from  Section  2.  Suppose  the  following  views  were  defined: 

Create  view  VI  as  select  *  from  PROCEDURE 
where  Bill_Amount  >  1000; 

Create  view  V2  as  select  *  from  PROCEDURE 

where  Bill_Amount  <=  1000  or  Bill_Amount  is  null; 

If  a  user  has  an  access  permission  on  both  VI  and  V2,  then  this  same  permission  can  be  inferred 
for  PROCEDURE. 

The  key  concept  in  the  above  rules  is:  Any  query  that  can  compute  T  can  be  used  to  infer 
permissions  on  T.  This  of  course  begs  the  question  of  how  such  queries  can  be  found.  This  issue 
is  sufficiently  important  that  we  devote  Section  3.3  to  it. 

Our  approach  also  handles  update  operations  on  views,  whose  implementation  is  expressed  as  a 
sequence  of  source-table  operations.7  In  all  cases,  the  view  update  is  replaced  by  a  sequence  of 
database  operations  (i.e.,  a  procedure)  that  carries  out  the  desired  update.  We  can  easily  adapt  the 


7  Current  database  tools  (e.g.,  Oracle’s  CASE  product)  handle  many  cases  of  view  update,  with  a  variety  of 
mechanisms.  Depending  on  tools  and  performance  issues,  the  desired  semantics  can  be  specified  as  a  stored 
procedure  or  method,  as  a  trigger,  or  as  a  metadata-driven  request  translator  in  the  development 
environment  or  user  interface.  Triggered  updates  may  execute  under  the  definer’s  permissions,  which  can 
be  checked  when  the  trigger  is  compiled. 
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inference  rules  to  such  situations,  by  replacing  “T  can  be  computed  by  query  Qi”  with  “T  can  be 
implemented  by  a  procedure  Pi”. 

Note  that  the  generated  operations  need  not  all  be  the  same  flavor  as  the  original.  For  example,  a 
request  to  delete  from  a  join  view  V  =  R1  join  R2  join  R3  might  translate  to  “Delete  from  Rl; 
Delete  from  R2;  Read  R3  to  check  integrity,  and  Abort  if  violated”.  The  access  permission  for  the 
view  update  is  the  AND  of  permissions  for  the  two  Deletions  and  the  Read. 

3.3  Imperfect  Solutions  to  the  Inference  /  Rewrite  Problem 

The  inference  rules  of  Section  3.2  define  the  allowable  access  permissions  on  a  table  T  by 
referring  to  the  set  of  all  queries  that  can  compute  T.  But  this  set  may  be  neither  robust  (e.g.,  new 
types  of  integrity  constraints  will  require  more  powerful  inference),  nor  feasible  to  enumerate. 

Our  approach  is  to  recognize  that  the  inference  rules  can  be  understood  both  theoretically  and 
pragmatically.  The  theoretical  mode  considers  the  set  of  all  queries  that  are  mathematically 
equivalent.  The  pragmatic  mode  considers  the  set  of  equivalent  queries  the  system  finds  feasible 
to  generate. 

The  theoretical  mode  is  sound  (in  the  sense  of  allowing  only  rewrite-justified  permissions)  and 
complete  (since  by  definition,  it  considers  all  rewrites).  But  it  is  no  basis  for  building  a  system.  If 
the  constraint  theory  is  rich,  the  problem  of  finding  all  queries  equivalent  to  some  Q  is 
undecidable;  at  intermediate  richness,  it  still  may  be  computationally  prohibitive.  Also, 
completeness  is  fragile  as  systems  evolve —  if  one  introduces  a  new  type  of  constraint,  the  rewrite 
process  may  no  longer  be  complete. 

The  pragmatic  mode  is  sound8,  but  not  complete.  A  pragmatic  access-permission  checker  does  its 
best  to  identify  a  rewrite  that  enables  the  query  to  execute,  but  does  not  guarantee  to  find  it.  It 
dodges  both  the  semantic  and  exponential-growth  problems.  We  argue  that  pragmatic  mode  is  the 
right  basis  for  building  a  system.  There  is  ample  precedent  for  DBMS  facilities  that  are  sound  but 
may  fail.  For  example,  some  SQL  queries  will  timeout  or  crash  due  to  huge  temporaries  -  thus 
the  set  of  executable  queries  depends  on  the  cleverness  of  the  query  processor. 

The  difference  between  theoretical  and  pragmatic  mode  only  involves  inferred  permissions.  The 
pragmatic  mode  would  begin  with  the  explicit  permissions  (rules  1  and  2),  and  then  heuristically 
infer  additional  ones;  hence  it  gives  at  least  the  permissions  of  current  SQL  systems.  Any 
additional  inferred  permissions  can  be  considered  a  convenience  to  the  user.  And  a  user  who  is 
cleverer  than  the  automated  search  can  do  the  replacement  manually. 

A  final  advantage  of  our  approach  is  that  we  can  take  advantage  of  query-processing  technology. 
Query  processors  are  a  critical,  large  (>  100K  lines  of  code)  well-funded  part  of  DBMS 
implementations.  By  using  the  rewrite  set  generated  by  the  query  processor,  the  security 
subsystem  can  improve  as  the  query  optimizer  improves. 

3.4  Exploiting  Rewrites 

This  section  explores  the  use  of  query  rewrite  in  security  semantics. 


8  This  observation  results  from  the  fact  that  the  inferred  access  predicate  is  the  OR  over  the  set  of  rewrites. 
Because  pragmatic  mode  considers  fewer  rewrites,  the  inferred  predicate  will  be  less  general. 
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3.4.1  View  Substitution 


View  substitution  is  the  process  of  replacing  a  mention  of  a  view  in  a  query  by  the  view’s 
definition  [Sto75].  For  example,  the  following  query  mentions  the  view  INSURANCE: 

select  Insurance_Co,  Total_Billed 
from  INSURANCE 
where  Year  =  1999 

It  can  be  rewritten  to  use  only  source  tables: 

select  p.Insurance_Co,  sum(r.Bill_Amount)  as  Total_Billed 

from  PATIENT  p,  PROCEDURE  r 

where  p.Patient_Id  =  r.Patient_Id 

group  by  Insurance_Co,  yearof(r.Date) 

having  yearof(r.Date)  =  1999 

Our  approach  gives  the  option  of  view  definition  without  separate  security  administration.  To 
users  who  have  the  necessary  permissions  on  the  source  tables,  the  view  is  simply  an  alternate 
interface  with  no  security  ramifications.  In  contrast,  the  current  SQL  standard  requires  that  view 
users  obtain  explicit  grants  from  the  view  owner. 

We  recognize  that  sometimes  executing  a  view  query  Qv(T]5  ...,Tn)  adds  knowledge,  making  the 
result  more  sensitive  than  its  inputs9.  We  cannot  solve  the  entire  aggregation  problem,  but  can 
protect  knowledge  embodied  in  the  view  definition.  This  requires  no  change  to  our  model  -  one 
simply  protects  the  view  text  and  (possibly  with  looser  permissions)  its  executable. 

3.4.2  Constraint-based  Simplifications 

If  the  user  queries  a  derived  table  V,  some  source  data  that  underlies  V  may  be  irrelevant  to  the 
query  result.  Query  processors  routinely  exploit  integrity  constraints  and  relational  algebra  to 
rewrite  queries  in  a  simpler  form.  In  terms  of  our  inference  rules,  a  query  needs  only  permissions 
for  the  data  it  accesses  (using  the  simplified  expression).  Such  inference  can  substantially 
increase  the  set  of  view  queries  that  users  are  allowed  to  execute. 

The  following  example  illustrates  the  benefit.  Suppose  the  source  database  has  a  foreign  key 
constraint  on  Patient  ld  (i.e.,  every  record  in  PROCEDURE  has  a  unique  corresponding 
PATIENT).  Suppose  also  that  the  derived  tier  contains  a  table  that  is  the  join  of  the  two  source 
tables,  as  in: 

Create  view  MED_INFO  as 
Select  p.*,  r.* 

From  PATIENT  p,  PROCEDURE  r 
Where  p.Patient_Id  =  r.Patient_Id 

Suppose  a  user  issues  the  following  query  Q1  on  the  derived  table: 

Select  Patient_Id,  Procedure_Performed 
From  MED_INFO 


9  The  other  side  of  the  aggregation  problem  is  to  prevent  two  items  from  being  revealed  together. 
Commercial  DBMSs  offer  no  protection  on  this  score,  nor  are  they  likely  to.  A  user  is  always  free  to  type 
in  a  query  that  retrieves  the  information  directly  from  source  tables,  in  one  or  multiple  queries. 
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A  straightforward  evaluation  of  Q1  requires  permissions  on  both  PATIENT  and  PROCEDURE, 
or  on  the  entire  view  MED_INFO.  But  note  that  the  selected  attributes  all  derive  from 
PROCEDURE,  and  (by  the  foreign  key  constraint)  no  PROCEDURE  records  drop  out  of  the  join. 
A  query  processor  can  rewrite  Q1  to  access  only  PROCEDURE,  so  permissions  on  PATIENT  are 
unnecessary. 

Suppose  now  that  a  user  issues  an  analogous  query  Q2  for  PATIENT  attributes: 

Select  Insurance_Co 
From  MED_INFO 
The  simplified  query  might  be: 

Select  Insurance_Co 
From  PATIENT 

Where  Patient_Id  in  (Select  Patient_Id  From  PROCEDURE) 

The  query  can  thus  be  executed  if  the  source  provides  permissions  on  the  Patient_Id  column  of 
PROCEDURE  (either  through  column  granularity  or  through  a  view). 

If  one  could  define  methods,  one  could  get  by  with  even  less  access.  Frequently  a  company  will 
allow  outsiders  to  request  a  single  phone  number,  but  not  to  download  a  telephone  directory. 
Analogously,  we  don’t  need  full  permissions  on  the  PROCEDURE  table;  we  just  need  to  know 
whether  a  given  patient  appears  in  the  table.  (Oracle’s  “reference”  privilege  is  somewhat  similar, 
but  executes  under  the  constraint-definer’s  privileges).  Let  isPresent(value,  column)  denote  a 
method  that  returns  TRUE  if  the  value  appears  in  the  specified  column.  Query  Q2  could  then  be 
rewritten  as: 

Select  Insurance_Co 
From  PATIENT 

Where  isPresent(Patient_Id,  PROCEDURE.Patient_Id) 

3.4.3  Rewrite  in  terms  of  other  views 

A  source  tier  can  use  views  to  provide  redundant  interfaces  to  its  data.  The  same  information 
might  be  available  through  a  source  table  and  through  a  view,  and  both  may  be  available  for 
queries.  This  means  that  there  can  be  many  ways  to  rewrite  a  query  in  equivalent  form.  In 
particular,  many  databases  (e.g.,  warehouses)  include  materialized  views,  and  query  optimizers 
are  beginning  speed  execution  by  rewriting  queries  to  use  them.  These  techniques  can  be  used  to 
find  additional  access  permissions. 

For  a  simple  example  of  such  query  rewrites,  consider  query  Q2  again.  The  source  administrator 
could  define  a  view  containing  the  non-confidential  information  from  PROCEDURE,  as  follows: 
Create  view  PUB_PROCEDURE  as 
Select  Patient  ld,  Doctor,  Date 
From  PROCEDURE 

This  view  can  then  be  used  to  rewrite  Q2  as: 

Select  Insurance_Co 
From  PATIENT 

Where  Patient_Id  in  (select  Patient_Id  from  PUB_PROCEDURE) 

The  fact  that  this  rewriting  exists  means  that  a  user  can  execute  Q2  if  she  has  access  permission 
on  PATIENT  and  PUB  PROCEDURE.  It  may  not  mean,  however,  that  Q2  will  be  executed  this 
way.  Once  the  system  has  established  that  the  user  has  permission  to  execute  the  query,  it  may 
execute  it  any  way  it  chooses.  The  chosen  execution  strategy  may  involve  accessing  tables  (such 
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as  PROCEDURE)  that  are  not  available  to  the  user,  but  improve  execution  efficiency.  The  system 
can  guarantee  that  the  user  will  see  only  information  she  is  allowed  to  see. 

3.5  Physical  Resource  Permissions 

Thus  far,  we  have  been  concerned  about  permissions  on  information,  applicable  wherever  the 
information  resides.  We  anticipate  that  most  enterprises  will  allow  physical  system  owners  to 
further  restrict  who  may  use  their  resources.  Motivations  include  financial  (only  those  who  pay), 
workload  management,  and  security  (high  security  machines  that  contain  copies  of  public 
information  do  not  invite  the  public  in). 

For  example,  suppose  that  the  CustomerService  department  of  a  company  has  gathered  a  great 
deal  of  customer  information,  and  imposed  appropriate  access  predicates  to  protect 
confidentiality.  Basic  information  (name,  address)  is  already  widely  used  (e.g.,  by  Shipping),  but 
other  departments  want  more.  Top  management  has  declared  the  information  to  be  an  enterprise 
resource  (subject  to  confidentiality).  But  CustomerService  argues  that  its  server  will  be  swamped, 
and  it  lacks  hardware  and  personnel  to  run  a  larger  operation. 

The  impasse  is  resolved  when  CustomerService  restricts  machine  access  to  a  role  Subscriber, 
whose  members  have  agreed  to  pay  a  fee  for  each  access  to  this  Customer  information. 
Information  permissions  are  checked  separately  (e.g.,  Shipping  should  not  be  allowed  to  see  the 
customer’s  payment  record).  Credit-Decisions,  which  makes  limited  use  of  the  data,  pays  a 
charge  for  each  customer  it  examines.  Marketing,  which  wants  heavy  usage,  makes  the  marketing 
DBA  a  subscriber.  She  downloads  weekly  to  the  marketing  server. 

In  order  to  support  such  scenarios,  we  allow  administrators  to  specify  physical  resource 
permissions  on  stored  tables.  For  example,  multiple  machines  might  maintain  copies  of  the  same 
data,  for  different  user  sets.  Physical  resource  permissions  determine  whether  the  execution 
strategy  may  use  a  physical  resource,  i.e.,  a  stored  table  or  (in  00  systems,  a  server). 

The  declaration  AllowPR(T,p)  specifies  that  physical  resource  permission  p  is  enabled  on  stored 
table  T  (a  source  or  a  materialized  view).  The  execution  strategy  must  be  expressed  in  terms  of 
stored  tables  for  which  the  user  received  such  explicit  allowances.  Inference  calculates  whether 
some  rewrite  can  provide  sufficient  physical  resources.  An  administration  tool  may  help  relate  the 
two  kinds  of  permissions,  e.g.,  to  identify  information  permissions  that  have  no  physical 
resources  to  satisfy  them.  (It  is  useful  to  allow  such  orphans,  rather  than  require  information 
policy  makers  to  deal  immediately  with  physical  resources.) 

Physical  resource  permissions  are  inferred  using  rules  analogous  to  those  of  Section  3.2,  but  with 
each  permission  set  suffixed  _PR.  Thus  each  table  T  (stored  or  view)  has  two  inferred  sets  of 
permissions.  Its  information  permissions  specify  who  is  allowed  to  access  T;  its  local  resource 
permissions  specify  who  will  be  physically  able  to  calculate  T,  based  on  enabled  access  to 
underlying  tables.  A  user  can  access  a  table  only  if  she  has  both  kinds  of  permissions  on  it. 

3.6  Determining  Enforcement  Strategies 

Federations,  warehouses,  and  centralized  DBMSs’  views  differ  in  where  one  tests  permissions. 
Warehouse  queries  never  reach  the  sources,  so  permissions  must  be  checked  at  the  warehouse.  A 
centralized  DBMS  often  tests  permissions  at  compile  time. 
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Federations  have  greater  flexibility,  assuming  that  all  tiers  know  the  requestor’s  identity.10 
Enforcement  at  the  sources  gives  the  data  providers  higher  assurance  because  the  federation  need 
not  be  trusted.  Enforcement  at  the  derived  tier  tends  to  be  more  responsive  and  intelligible  to 
users.  Enforcing  at  both  tiers  would  combine  both  advantages,  and  may  be  cheap  (especially  if 
done  largely  at  compile  time). 

In  an  ideal  world,  these  distinctions  would  not  concern  business  decision-makers.  Instead,  the 
business  decision  would  specify  requirements  for  assurance  and  responsiveness,  and  a  tool  (or  an 
always-available  technical  expert)  would  determine  what  access  controls  each  tier  enforced. 


4  Conclusions  and  Open  Questions  /  Research  Issues 

4.1  What  We  have  Accomplished 

Several  important  classes  of  systems  (federations,  warehouses,  conceptual  views)  can  be 
described  as  “multi-tier  databases”.  Current  metadata  management  tools  offer  little  help  in 
coordinating  any  but  the  most  basic  metadata  (e.g.,  tables  and  their  attributes).  As  a  consequence, 
metadata  is  frequently  absent  or  inconsistent,  causing  security  vulnerabilities  on  one  hand,  and  on 
the  other,  inadequate  accessibility. 

Our  scenarios  illustrated  practical  requirements  for  managing  security  metadata  in  such 
environments.  We  showed  the  need  for  communicating  access  permissions  between  different  tiers 
in  the  database.  We  also  illustrated  the  need  for  comparison  capabilities,  both  for  ordinary 
administration  and  for  auditing.  The  scenarios  further  illustrated  extra  permissions  granted  when 
a  view  has  filtered  or  summarized  information. 

We  then  sketched  a  technical  foundation  for  coordinating  access  permissions.  The  key 
innovations  that  helped  us  simplify  the  model  were  to: 

*  Base  the  theory  on  query  rewrite,  rather  than  building  a  more  complex  theory  of  permission 
inference. 

*  Specify  the  global  information  permissions  separately  from  local  resource  controls.  Each  has 
a  strong  inference  rule,  and  the  desired  behavior  is  obtained  as  their  intersection. 

A  series  of  examples  showed  how  query  rewrites  permitted  additional  access.  We  then  used  the 
same  theory  to  handle  non-Read  operations,  and  other  granularities. 

The  theory  in  the  paper  is  neither  startling  nor  complex.  Paradoxically,  this  is  one  of  the  key 
strengths  of  the  paper.  The  security  administration  problem  for  warehouses  and  federations  is 
broad  and  murky.  We  have  identified  a  problem  whose  solution  can  give  significant  practical 
benefit,  and  can  be  implemented  using  relatively  simple  theory. 

4.2  Technology  Insertion  Issues 

It  seems  quite  feasible  to  add  metadata-propagation  (e.g.,  for  access  permissions)  to  existing 
schema-management  environments  (for  federations  and  warehouses).  If  we  could  automate 
coordination  of,  say,  50%  of  the  metadata,  we  could  make  federation  and  warehouse 
administration  cheaper  and  more  effective.  We  believe  that  metadata  propagation  capabilities 
would  be  an  excellent  addition  to  a  vendor’s  tool  suite.  Reference  [Ros98b]  shows  how  such  a 
tool  might  look. 

10  Some  products  send  all  requests  from  “federation”,  a  privileged  subject. 
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Security  administration  seems  a  good  place  to  begin  metadata  propagation  tools.  Security  is 
mandatory.  In  contrast,  it  is  harder  to  provide  strong  incentives  for  data  quality  and  many  other 
forms  of  metadata. 

Perhaps  the  biggest  technical  challenge  is  to  exploit  rather  than  rebuild  query  rewrite  technology, 
in  generating  propagation  rules.  First,  query  rewrite  techniques  require  that  derivations  be 
understandable,  e.g.,  be  in  SQL  and  definitely  not  in  Java.  Second,  we  want  to  be  able  to  submit 
a  query  for  rewrite  but  not  execution. 

4.3  Open  Research  Problems 

The  multi-tier  paradigm  opens  many  questions  for  security  and  other  research.  The  issues  in 
section  4.2  apply  to  many  kinds  of  metadata.  The  discussion  below  focuses  on  access 
permissions. 

First,  we  need  a  strategy  for  dealing  with  different  permission  granularities.  Some  organizations 
or  DBMSs  may  permit  multiple  granularities  simultaneously,  while  others  will  insist  on  a  favored 
one. 

Second,  once  the  policy  is  known,  administrators  need  help  in  devising  an  enforcement  strategy. 
The  software  used  at  the  different  tiers  may  differ  in  flexibility,  assurance,  and  granularity. 

Third,  we  need  a  theory  of  permission  deltas.  Even  a  single  table  can  involve  an  intimidating 
amount  of  metadata.  We  want  the  ability  to  propose  a  small  change,  and  have  just  the  small 
change  be  seen  at  other  tiers.  Also,  when  a  view’s  users  want  more  permissions  than  the  view 
offers,  we  need  algorithms  that  generate  a  minimal  view  on  which  one  can  assert  the  additional 
permissions. 

Fourth,  SQL’s  access  controls  on  views  are  too  inflexible  to  apply  to  federations.  They  require 
that  each  view  defmer  be  trusted  by  owners  of  source  tables,  and  be  willing  to  act  as  security 
administrator.  And  they  don’t  allow  the  separate  administration  of  local  physical  resources.  As 
much  as  possible,  we  would  like  to  see  a  federation  or  data  warehousing  system  as  an  integrated 
database.  Since  SQL  dominates  relational  databases,  we  want  to  integrate  our  approach  with  SQL 
security  capabilities. 

Fifth,  we  intend  to  investigate  the  possibility  of  security  components.  Enterprise  Java  Beans 
controls  transaction  behavior  via  property  sheets;  perhaps  a  similar  approach  would  work  here. 

Sixth,  the  essence  of  our  approach  is  to  use  some  simple  principles  to  propagate  security  metadata 
between  the  tiers.  We  believe  that  it  would  be  fruitful  to  apply  a  similar  approach  to  other  forms 
of  metadata.  For  non-security  issues,  the  chief  problems  are  to  devise: 

*  theory  for  propagating  other  kinds  of  metadata  (e.g.,  data  pedigree,  credibility,  precision, 
timeliness),  through  a  wide  set  of  query  operators  (e.g.,  outeijoin,  pivot); 

*  a  component  framework  that  allows  administrators  to  incrementally  insert  and  customize  the 
ever-increasing  set  of  propagation  rules  [Ros99a]. 

Finally,  we  have  been  concerned  with  semantics,  not  with  algorithmic  efficiency.  Inference  seems 
polynomial-time  (in  the  size  of  the  query  rewrite  space),  but  greater  efficiency  is  desired, 
especially  for  avoiding  full  recomputation  when  a  few  permissions  are  added  or  revoked. 
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Abstract 

We  consider  the  role  of  constraints  in  maintaining  both  secrecy  and  integrity  in  a 
multilevel  secure  database.  In  a  multilevel  database,  certain  integrity  and  classification 
constraints  create  a  secrecy  problem  since  data  additions,  deletions  or  modifications 
require  accessing  data  at  higher  levels.  In  many  cases,  however,  these  constraints  may  be 
approximated  by  a  series  of  simpler  constraints,  called  level-valid  constraints.  Level- 
valid  constraints  do  not  require  access  to  any  data  that  is  classified  higher  than  the  data 
to  be  modified.  Moreover,  they  meet  the  integrity  requirements  since  any  database  state 
that  satisfies  the  level-valid  constraints  also  satisfies  the  multilevel  constraints.  Simple 
tests  are  developed  to  ensure  the  validity  of  proposed  level-valid  constraints  and  these 
constraints  are  derived  for  common  cases  of  multilevel  constraints. 

1.  Introduction 

Consistency,  or  data  integrity,  in  databases  is  usually  achieved  by  associating  with 
each  database  a  set  of  constraints.  The  database  management  system  (DBMS)  has  the 
responsibility  to  ensure  that  these  constraints  are  satisfied  by  the  database  state  at  all 
times.  Generally,  this  is  done  by  checking  the  constraint  for  each  tuple  that  is  added, 
deleted  or  modified.  A  multilevel  secure  (MLS)  DBMS  has  the  additional  responsibility 
of  preventing  improper  disclosure1 2  of  information  either  by  direct  or  indirect  means.  It  is 
well  known  that  there  are  inherent  conflicts  in  MLS  databases  between  the  secrecy 
requirements  and  certain  types  of  integrity  constraints  [DENN86].  In  particular,  it  appears 
impossible  to  enforce  certain  integrity  constraints  without  violating  the  secrecy 
requirements.  Since  the  enforcement  of  multilevel  constraints  involves  a  trade-off 
between  secrecy  and  integrity,  the  usual  approach  is  to  accept  one  or  the  other. 

In  this  study,  we  show  how  it  is  often  possible  to  maintain  secrecy  while  still 
enforcing  integrity.  The  approach  taken  will  be  to  translate  the  original  multilevel 
constraint,  whose  satisfaction  requires  the  MLS  DBMS  to  access  both  High  and  Low 
data,  into  a  collection  of  level-valid 2  constraints.  Each  level-valid  constraint  has  a  fixed 
security  level  associated  with  it  and  is  evaluated  by  referencing  only  data  at  or  below  that 
level.  In  a  sense,  then,  we  polyinstantiate  the  constraint  rather  than  the  tuple.  That  is. 


1  In  this  paper,  we  address  only  mandatory  access  controls 

2  From  [QIAN94a]. 
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instead  of  having  one  constraint  that  applies  to  all  levels,  each  level  will  have  its  own 
constraint  that  only  applies  to  that  level. 

More  formally,  suppose  we  have  a  database  state,  D  and  a  multilevel  constraint  M. 
To  enforce  both  the  constraint  and  the  security  policy,  we  wish  to  replace  M  by  a 
collection  of  level-valid  constraints  L,  such  that: 

L  -  {L\,  L2,  —Ln,  M }  (where  Li  and  Lj  are  not  necessarily  unique) 

1 .  Each  Lj  in  L  is  a  level-valid  constraint  at  level  j,  and 

2.  If  D  satisfies  level-valid  constraint  Lj,  then  D  also  satisfies  Lj+i. 

At  the  highest  level,  the  constraint  is  still  M,  so  there  may  exist  database  states 
that  are  allowable  under  the  original  multilevel  constraint  but  not  under  the  derived  level- 
valid  ones.  Processes  allowed  to  modify  the  database  in  a  way  that  meets  the  original 
multilevel  constraint,  but  not  the  appropriate  level-valid  constraint,  will  still  have  to  be 
trusted  at  the  higher  level  (note  that  this  higher  level  constraint  is  not  necessarily  M). 
Thus,  our  approach  is  still  a  compromise  between  security  and  integrity.  However,  the  use 
of  such  trusted  processes  is  reduced  by  this  scheme.  Intuitively,  if  the  level-valid 
constraint  represents  all  the  pertinent  information  available  at  the  lower  level,  the  scheme 
would  minimize  the  use  of  trusted  processes.  Actually  forming  constraints  that  minimize 
these  trusted  processes  is  still  an  area  of  research,  however. 

1.1  Previous  Work 

Within  a  “multilevel  secure”  model,  as  in  conventional  databases,  constraints  are 
a  common  means  of  controlling  not  only  integrity,  but  also  access  and  inference  control. 
Other  researchers  note  the  issue  of  conflict  between  the  multilevel  security  and  database 
integrity  requirements  in  DBMS  design.  In  particular,  [DENN86,  AKL87,  MEAD88, 
BURN90,  and  MAIM91],  have  all  addressed  this  issue.  Thuraisingham  and  Ford 
[THUR95],  Sandhu  and  Jajodia  [SAND93],  and  Qian  [QIAN94]  have  addressed 
polyinstantiation  (i.e.  multiple  data  instances)  issues  associated  with  integrity  constraints. 
Gupta  and  Widom  [GUPT93]  propose  a  similar  technique  for  local  verification  of 
constraints  in  distributed  databases,  although  no  security  issues  are  addressed.  While 
some  of  the  theoretical  and  design  issues  for  this  approach  were  discussed  in  [JAJ095], 
this  paper  focuses  upon  the  mechanics  and  the  process  of  translating  multi-level 
constraints  into  equivalent  sets  of  level-valid  constraints. 

1.2  Example  1. 

Suppose  we  have  the  relation: 

EMP (Name,  Salary,  Position ):  containing  the  names,  salaries,  and  positions  of  the 
employees  in  a  law  enforcement  agency.  There  are  three  positions:  patrolman, 
investigator,  and  special  agent.  The  constraints  are: 

1)  all  patrolman  salaries  are  less  than  any  investigator’s  salary; 

2)  all  investigator  salaries  are  less  than  any  special  agent’s  salary. 
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The  classification  levels  are:  1)  patrolman  records  are  classified  confidential  (C); 
2)  investigator  records  are  classified  secret  (5);  3)  special  agent  records  are  classified  top 
secret  (75).  Subjects  at  one  level  are  not  allowed  to  read  information  at  a  higher  level,  nor 
are  they  allowed  to  write  at  any  other  level. 

If  a  new  patrolman  is  hired,  that  record  is  automatically  classified  C,  and  inserted 
by  a  C-level  subject.  The  database  must  decide  if  this  is  allowed.  At  the  C  level,  the  level- 
valid  constraint  is: 

Lq:  New  patrolman  salary  must  be  less  than  or  equal  to  the  highest  existing 
patrolman  salary. 

This  constraint  is  sufficient  to  guarantee  that  a  new  tuple  does  not  invalidate  the 
original  constraint. 

The  highest  cleared  category,  special  agent,  has  access  to  all  lower  classified 
information  and  needs  no  special  constraint,  so: 

LTs:  New  special  agent  salary  must  be  higher  than  the  highest  existing 
investigator  salary. 

Finally,  if  a  subject  attempts  to  write  a  new  investigator  tuple,  there  are  two 
checks  that  must  be  performed:  the  salary  value  must  be  higher  than  any  patrolman,  but 
lower  than  any  special  agent.  This  will  require  a  conjunctive  constraint  to  specify  both 
conditions  as  follows: 

Ls:  New  investigator  salary  must  be  less  than  the  highest  existing  investigator 
salary,  and  greater  than  the  highest  paid  patrolman. 

This  constraint  is  sufficient  to  guarantee  that  a  new  tuple  satisfies  both  of  the  orig¬ 
inal  multilevel  constraints. 

This  example  illustrates  integrity  constraints  which  are  affected  only  by  insert 
operations  and  are  sufficient  to  enforce  the  original  multi-level  constraint.  Note  that 
constraints  that  are  enforced  during  an  insert  operation  may  be  different  from  the 
constraints  that  are  enforced  during  a  delete  operation. 

The  next  sections  will  formalize  and  generalize  the  approach  to  provide  methods 
of  forming  these  level-valid  constraints  as  well  as  assurances  of  their  correctness. 

2.  THE  GENERAL  SOLUTION 

2.1  Notation 

The  first  necessary  step  is  to  define  a  specific  formalism  for  constraints. 
Constraints  are  generally  formed  by  comparing  characteristics  (given  by  a  function)  of 
two  sets  of  data  (given  by  a  database  view).  This  can  be  formalized  in  the  following 
definition. 

Definition  of  Constraint:  a  constraint  is  an  expression  of  the  form: 

fi(qi(./?))  0  f2(q2(/?)).  Which  is  true  for  any  valid  database  state. 
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Where:  qi,  q2  are  database  views  on  the  relation  R;  fi,  f2  are  functions  defined  on 
the  data  revealed  by  the  database  views  and  ©  defines  a  partial  order  relating  the  values 
derived  by  fi,  f2-  To  avoid  the  complexities  of  considering  the  database  representation,  we 
adopt  the  universal  relation  viewpoint,  so  that  the  relation  R  is  equivalent  to  the  entire 
database. 

The  functions  are  defined  using  mathematical  notation,  i.e.  f(x)=y,  where  x  is  the 
argument  of  the  function.  Note  that  fi,  f2  may  be  any  user  defined  functions,  including 
those  implemented  by  means  of  triggers,  procedures  or  object  oriented  methods. 
Functions  however,  are  limited  to  acting  upon  the  information  included  in  the  view 
defined  as  their  argument.  Similarity,  0  may  be  any  partial  order,  including  functional 
dependence  from  relational  database  theory.  However,  commercial  database  systems  only 
allow  for  a  few  comparators  so  in  this  study  we  assume  that  fj,  f2  yield  either  a  numerical 
value  or  a  set  of  string  values.  We  also  assume  0  is  one  of  the  standard  comparators;  (>; 
<;  <;  >;  =)  for  numeric  values,  or  the  subset  inclusion  operator  “c”,  or  its  inverse  for 
string  values  (or  sets  of  numerics).  In  later  discussions,  Q  will  denote  “0  or  =  ”,  so  if  0  = 
<,  then  £2  s  <. 

For  any  multi-level  database,  some  of  the  data  may  be  viewed  by  a  subject  cleared 
to  level  L,  namely  that  information  classified  no  higher  than  level  L.  We  will  denote  this 
restricted  view  by  the  subscript  L.  Therefore,  Rl  will  denote  that  subset  of  R  which  is 
visible  at  level  L. 

The  function  and  view  based  notation  presented  here  is  more  intuitive  than 
previously  proposed  notations  and  allows  the  database  itself  to  evaluate  the  constraints.  It 
maintains  separation  of  important  concepts  (views,  functions,  and  tests),  allows  for 
multiple  aggregate  functions,  and  is  not  restricted  to  using  base  relations  or  conjunctions 
of  simple  selects. 

In  our  notation,  the  constraint  “all  patrolman  salaries  are  less  than  any  investi¬ 
gator’s  salary”  becomes: 

MAX(select  Salary  from  EMP  where  Position  =  ‘ patrolman’)  <  MIN(select 
Salary  from  EMP  where  position  =  ‘ investigator ’). 

More  complicated  constraints  may  require  the  following  extension: 

Definition  2:  A  complex  constraint  is  an  expression  of  the  form 

IQ  AND  IQ 

where  either  both  IQ  and  IQ  are  simple  constraints  as  defined  in  Definition  1,  or 
IQ  is  a  simple  constraint  and  IQ  is  a  complex  constraint. 

2.2  Sufficiency 

The  critical  feature  of  this  notation  is  the  fact  that  it  provides  us  with  a  way  to 
order  the  relations  using  the  comparator  0.  The  fact  that  the  relations  are  ordered  may 
allow  us  to  derive  some  simple  tests  for  determining  if  a  tuple  may  be  added  to  (or  deleted 
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from,  or  modified  in)  the  database.  Theorem  1  uses  this  ordering  to  establish  our  a 
testable  condition. 

Theorem  1  -  Tuple  Addition:  Given  a  constraint,  f((qi(R))  0  f2(q2(R)),  which  is 
known  to  be  satisfied  by  the  current  state  of  the  database,  and  a  tuple,  t,  satisfying  the 
following  two  conditions: 

(1)  f1(q,(Rur))^fi(qi(R))  and 

(2)  f2(q2(R))£2f2(q2(Rur)), 

then  the  database  will  still  satisfy  the  constraint  after  t  is  added. 

[Theorem  1  may  be  modified  to  address  delete  and  modify  in  a  straightforward 
manner.] 

Theorem  1  specifies  two  conditions,  one  for  each  expression  in  the  constraint.  We 
can  therefore  define  two  sets  of  valid  tuples,  one  for  each  condition.  Those  tuples  in  both 
sets  may  be  added  to  the  relation  and  still  satisfy  the  original  constraint. 

[For  real-life  complex  databases.  Theorem  1  may  have  to  be  implemented  using 
"before  and  after  images".  The  values  of  fi(qi(R  u  t))  and  f2(q2(R  u  t))  may  need  to  be 
calculated  from  the  "after"  image,  that  is,  after  t  is  inserted  and  committed,  to  the 
database.  Otherwise  there  may  be  additional  assertions,  triggers,  constraints  and 
procedures  that  would  change  other  data  in  the  database  view.] 

Fortunately,  in  many  cases  of  practical  interest,  a  substantial  number  of  tuples  are 
in  both  sets.  It  is  even  common  for  a  tuple  to  influence  only  one  of  the  conditions  in 
Theorem  1,  while  the  other  condition  is  satisfied  by  all  tuples.  For  example,  if  f2(R)  is 
equal  to  a  constant,  k,  then  it  is  true  that  f2(q2(R))  =  f2(q2(R  u  t))  =  k,  regardless  of  what 
tuple  t  is  added  to  the  database.  In  such  cases,  tuples  only  influence  one  condition,  so  the 
conjunction  does  not  present  a  serious  problem. 

Example  2.  Consider  the  constraint:  “all  patrolman  salaries  are  less  than  any 
investigator’s  salary”.  From  Theorem  1,  it  follows  that  we  need  to  satisfy  the  two  condi¬ 
tions: 


1)  MAX  [select  Salary  from  (EMP  (J  t)  where  Position  =  patrolman }  < 

MAX  [select  Salary  from  EMP  where  Position  =  patrolman}  and 

2)  MIN  { select  Salary  from  EMP  where  Position  =  investigator }  < 

MIN{ select  Salary  from  (EMP  u  t)  where  Position  =  investigator}. 

Patrolman  tuples  with  salaries  less  than  or  equal  to  the  present  maximum  will  not 
change  the  value  of  the  first  condition  in  (1).  All  these  tuples  will  therefore  satisfy  (1). 
All  patrolman  tuples  will  also  satisfy  (2)  since  it  is  unchanged  by  their  addition, 
regardless  of  their  salary.  The  addition  of  an  patrolman  tuple  therefore  only  requires 
evaluation  of  one,  level-valid  constraint: 
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/c:  “if  /.position  =  patrolman ,  then  t.Salary  <  MAX{ select  Salary  from  EMP 
where  Position  =  patrolman } . 

Note  that,  if  each  tuple  affects  only  one  of  the  views  (qi(R))L  or  (q2(R)>L,  then: 

(qi(R))L  n  (q2(R))L  =  0,  (Separation  Condition) 

and  Theorem  1  may  be  applied  at  level  L.  This  is  a  very  powerful  and  useful  test. 
It  provides  a  very  simple  method  to  determine  when  the  “multilevel”  constraint  may  be 
separated  into  distinct  classification  levels  or  compartments.  Obviously,  if  the  Separation 
Condition  holds,  each  new  tuple  will  affect,  at  most,  one  of  the  test  conditions  in 
Theorem  1.  This  affected  condition  is  visible  at  level  L,  and  is  the  only  condition  that 
needs  to  be  evaluated  in  order  to  prove  the  continued  validity  of  the  multilevel  constraint. 

3.  COMMON  DBMS  OPERATIONS 

3.1  Automated  Constraint  Derivation 

The  next  step  is  to  automatically  propose  level-valid  constraints  which 
may  represent  sufficient  conditions  for  the  addition  of  (deletion  from,  modification  to)  a 
tuple  in  a  relation.  We  do  not  claim  to  have  evaluated  every  variation  of  such  constraints, 
nor  to  find  an  optimal  solution  to  the  problem.  We  have,  however,  attempted  to  partition 
the  problem  and  devise  appropriate  rules  for  each  node  in  the  taxonomy.  Using  the  results 
will  require  assigning  the  constraint  to  the  appropriate  node  and  applying  the 
corresponding  rules. 

To  make  it  possible  to  automate  the  derivation  of  level-valid  constraints,  we  will 
assume  that  the  addition  of  a  tuple  does  not  affect  f2(q2(R))-  We  will  also  assume  that  the 
addition  or  deletion  of  a  tuple  does  not  cause  and  "cascade"  effects  due  to  other  triggers 
or  procedures.  The  technique  could  be  extended  to  allow  for  such  circumstances,  but  the 
results  would  have  to  be  framed  in  terms  of  the  less  intuitive  before  and  after  images.  In 
the  following  procedures,  we  are  required  to  compare  views  at  differing  classification 
levels.  Since  we  must  do  this  comparison  at  the  lowest  of  these  levels,  some  changes 
must  be  made  to  the  view  definition.  In  transmogrifying  a  high  level  view  into  a  lower 
level  view  we  may  either  create  a  bigger  or  a  smaller  view  (disjoint  views  would  have  no 
value).  Much  of  the  following  discussion  formalizes  this  rather  simple  observation. 

The  problem  is  approached  on  a  case-by-case  basis.  This  approach  is  appropriate 
since  there  are  only  a  limited  number  of  database  operations  and  comparators  to  be 
analyzed.  In  commercial  databases,  choices  of  functions  are  limited  to  the  common  aggre¬ 
gate  functions  of  COUNT,  MAX,  MIN,  and  SUM.  The  choices  for  comparators  are  simi¬ 
larly  limited  to  <,  >,  <,  >,  =,  □,  or  c.  Each  combination  of  a  database  operation  and 
comparator  comprises  a  case. 


192 


3.2  Relationship  of  Components 

Assume  a  multilevel  constraint  M  =  f|(qi(R))  0  f2(q2(R)),  where  the  addition  of  a 
tuple  at  level  L,  t,  changes  the  value  of  f|(qt(R))  but  does  not  affect  f2(q2(R)).  We  will 
derive  a  view  q2(RL)  such  that: 

fi(qi(R))  Q.  fi(q3(RL))  always  holds,  and  define  the  level-valid  constraint  as: 

L  =  f,(q3(RL))^f2(q2(R))L. 

Then,  by  transitivity,  if  L  holds,  M  holds.  The  only  unknown  is  the  view  definition  q3(RL). 
Note  that  the  query  q3  is  submitted  by  a  subject  at  level  L  and  hence  can  only  operate  on 
Rl  -  the  restriction  of  R  to  level  L.  The  query  q2,  however,  is  submitted  by  a  High  cleared 
subject  and  so  q2(R)  may  contain  attributes  classified  higher  than  L.  In  order  to  compare 
the  two  relations,  q2(R)  must  be  restricted  to  level  L,  (i.e.  (q2(R))0-  Even  though  qi(R) 
and  q3(RL)  may  have  differing  attributes,  they  could  contain  some  common  tuples.  A 
tuple  in  qi(R)  will  match  a  tuple  in  q3(RL)  if  the  two  tuples  have  identical  primary  keys 
and  (qi(O)L  =  q3(A)-  We  are  especially  interested  in  the  situation  where  all  tuples  in  one 
set  are  also  in  the  other.  Either  q3(RL)  or  qt(R)  could  be  the  larger  set  (called  the  superset) 
and  have  either  additional  tuples,  or  longer  tuples.  There  are  therefore  two  generic  types 

of  views  of  interest  to  us:  the  superset  case  where  qi(R)Cq3(RL)  and  the  subset  case 

where  q3(RL)Cqi(R). 

Superset  Views:  qi(R)Cq3(RL)) .  All  tuples  in  the  multilevel  view  qi(R)  are  also  in 
q3(RL),  and  the  level-valid  view  q3(RL)  may  be  larger. 

These  types  of  level-valid  constraints  are  frequently  formed  by  deleting  those 
clauses  restricting  the  view  to  high  classified  attributes.  Thus  the  low-classified  view  “ID 
number  of  all  SR71  airplanes”  is  certainly  a  larger  set  than  the  high-classified  view  “ID 
number  of  all  SR71  airplanes  on  spy  missions”. 

Subset  Views:  q3(RL)  C  qi(R).  All  tuples  in  the  level-valid  view  q3(RL)  are  also  in 
the  multilevel  view  (qi(R)),  and  the  multilevel  view  qi(R)  may  be  larger. 

Subset  views  are  related  to  the  aggregation  problem  where  a  subset  of  High  infor¬ 
mation  is  classified  Low  either  by  design  or  because  it  is  common  knowledge.  This  might 
occur  if  the  view  “ED  number.  Mission,  of  all  SR71  airplanes”  is  classified  High,  but  the 
view  “ID  number  of  all  SR71  airplanes”  is  available  to  flight  crews  and  so  must  be 
classified  Low.  This  can  also  occur  if  certain  attributes  are  classified  High,  or  if  cover- 
stories  are  implemented.  The  Low-level  view  results  in  a  subset  of  the  High-level  one. 

3.3  Additions/Deletions 

Fortunately,  for  the  database  functions  being  considered  (COUNT,  MAX,  MIN, 
SUM),  there  is  a  direct  relationship  between  the  value  of  the  function  and  the  size  of  the 
set  operated  on  by  that  function.  That  is,  MAX(A)  <  MAX(B)  if  A  c  B,  and  similarly  for 
COUNT  and  SUM  (of  positive  values).  For  the  functions  MIN,  and  SUM  (of  negative 
values)  there  is  an  inverse  relationship,  so  f(A)  <  f(B)  if  BcA.  Therefore,  given  and  0, 
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we  can  determine  whether  q3(RL)  should  be  a  subset  or  superset  view.  Indeed  there  are 
only  four  combinations,  or  cases,  to  consider. 

Case  1.  Assume: 

(1)  fi  is  COUNT,  MAX  or  SUM  (for  positive  values  of  t); 

(2)  0  is  <,  <  = ,  or  c. 

(3)  q3(RD  is  a  subset  view. 

If  adding  a  new  tuple  increases  fi(qi(R)),  then  fi(q3(RD)  will  not  increase  by  a 
greater  amount,  so 

fi(q3(Ri.))  &  fj(qi(R))  always  holds. 

For  example:  COUNT  (SELECT  (ID-Number  FROM  DB  WHERE  Plane_Type=SR71 
AND  Mission_Classification  <  Confidential))  <  COUNT (SELECT (Name  FROM  DB 
WHERE  plane_type=SR71))  will  always  hold,  regardless  of  Mission_Classification. 

Case  2.  Assume: 

(1)  fi  is  MIN,  or  SUM  (for  negative  values  of  t); 

(2)  ©  is  >,  >,  =,  or  3. 

(3)  q3(RO  is  a  subset  view. 

If  adding  a  new  tuple  decreases  fi(qi(R)),  then  fi(q3(RO)  will  not  decrease  by  a 
greater  amount,  so 

fi(q3(Ri,))  £2  fi(qi(R))  always  holds. 

For  example:  MIN(SELECT(Emp_Pay  FROM  (DB  WHERE  Job  =  analyst)))  > 

MIN (SELECT(Emp_Pay  FROM  DB  WHERE  Job  =  analyst  OR  Job  =  agent))  will 
always  hold  (assume  “agent”  records  are  classified  higher  than  “analyst”  records). 

Case  3.  Assume: 

(1)  fi  is  COUNT,  MAX  or  SUM  (for  positive  values  of  /); 

(2)  0  is  >,  >,  =,  or  3. 

(3)  q3(RD  is  a  superset  view. 

Then  an  increase  to  fi(q3(RO)  will  not  always  increase  fj(qi(R)),  so: 
fi(q3(RL))  Q  fi(qi(R))  always  holds. 

For  example:  COUNT  (SELECT  (N  ame  FROM  DB  ))  >  COUNT  (SELECT  (N  ame  FROM 
DB  WHERE  Real_Agency  .eq.  "CIA"))  will  always  hold,  regardless  of  the  value  of 
Real_Agency. 

Case  4.  Assume: 

(1)  f  is  MIN,  or  SUM  (for  negative  values  of  t); 

(2)  0  is  <,  <,  =,  or  c. 

(3)  q3(RO  is  a  superset  view. 


194 


Then  if  adding  a  new  tuple  decreases  fi(q3(Ri.))  it  will  not  always  decrease 
f,(qi(R)),  so: 

f i (qsCRu))  &  fi(qi(R))  always  holds. 

For  example:  MIN(SELECT(Mission_Cost  FROM  DB  ))  < 

MIN(SELECT(Mission_Cost  FROM  DB  WHERE  Mission  .eq.  "spy"))  will  always  hold, 
regardless  of  the  value  of  Mission. 


For  other  combinations  of  q3,  fj,  and  ©  (i.e.  fi  =  COUNT,  0  =  >,  and  q3(RL,) 
cqi(R)0,  there  will  exist  a  level-valid  constraint  which  is  sufficient  to  validate  the 
multilevel  constraint  for  tuple  deletions.  That  is,  for  the  complimentary  conditions,  tuples 
can  be  deleted  (but  not  added)  without  checking  the  original  multilevel  constraint, 
although  the  multilevel  constraint  must  still  be  checked  if  tuples  are  added  to  ensure  that 
the  new  set  is  still  small  enough  to  satisfy  the  constraint.  If  f  =  identity,  f(qi(R))  =  qi(R) 
so  (qi(R))L  =  q3(R0-  In  dealing  with  identity  functions,  we  must  establish  both  subset  and 
superset  conditions,  so  that  (qi(R))L  =  qsCRD- 

3.4  Modify  Operations 

A  “modify”  operation  cannot  be  handled  as  two  separate  operations  but  must  be 
considered  as  an  atomic  transaction.  The  basic  principles  derived  above  must  still  apply, 
that  is,  the  Low  view  will  still  be  either  a  subset  or  a  superset  of  the  High  view.  However, 
it  is  no  longer  clear  if  the  function  fj  is  increasing  or  decreasing.  In  fact,  this  will 
normally  depend  upon  the  actual  values  for  the  attributes  in  the  new  and  old  copies  of 
tuple  t.  For  example,  if  fi  =  SUM,  then  fi  is  increasing  when  |q3(f)|>0,  and  fj  is  decreasing 
when  |q3(f)|<0. 


Table  1:  Level  valid  tuple  modification  constraints 


q3  -  Superset 
(i.e.  qi(R)cq3(RL)) 

q3  -  Subset 
(i.e.  q3(RL)Cqi(R)) 

f. 

© 

conditions  on 
t0  and  tn 

fi 

© 

conditions  on 
t0  and  ta 

all 

none 

5— 

all 

none  . 

jg 

>  = 

- 5 

none 

>  = 

- 5 

q3(tn)  0q3(to» 

jg 

<  = 

— 5 

q3(tn)  ©q3(?o)) 

<  = 

none 

SUM 

q3(to)-q3(tn)  ^0 

SUM 

<,= 

none 

SUM 

>  ~ 

— 5 

none 

SUM 

>,= 

q3(to)~q3(tn)  o 

>  = 

qsta))  ©  q3(to) 

>  = 

none 

<,= 

none 

<  = 

q3(tn)  ©q3(to)) 
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Table  1  presents  these  additional  conditions  which  must  be  evaluated  in  order  to 
determine  the  behavior  of  these  functions.  These  conditions  become  simple  tests  for  the 
validity  of  modifying  tuples.  In  Table  1,  L  =  fi(q3(RL-  t0  u  t„))  ©  f2(q2(R))L  is  the 
constraint  for  modification  of  tuples  (to— >tn)  where  the  RHS  of  fi(qi(R))0  f2(q2(R))  is 
unaffected  by  tuple  modification. 

3.5  Limitations 

If  any  of  the  following  are  true  we  can  make  no  statement  concerning  the 
existence  of  a  level-valid  constraint:  (1)  q3(R0  is  neither  a  subset  nor  a  superset  of  qi(R); 
(2)  fi  is  not  monotonic  with  respect  to  set  sizes;  or  (3)  0  does  not  specify  a  partial  order 
relation.  This  does  not  mean  that  such  level-valid  constraints  do  not  exist,  merely  that 
their  existence  cannot  be  proven  by  this  mechanism.  Usually  heuristic  analysis  is 
required. 

Fortunately,  the  situation,  fi(q3(RL))  =  fi(qi(R))L,  is  quite  common  and  satisfies 
both  Superset  Class  and  Subset  Class  requirements.  In  such  a  case,  level-valid  constraints 
will  exist  for  both  addition  and  deletion  of  tuples. 

3.6  Constraint  View  Derivation 

We  have  two  choices  for  views  (subset  or  superset),  two  choices  for  functions 
(increasing  or  decreasing),  and  only  two  real  choices  for  comparators  (<,  >).  In  practice, 
only  the  view  in  the  level-valid  constraint  will  differ  from  the  one  in  the  multilevel  valid 
constraint.  We  will  examine  each  choice  in  more  detail  and  summarize  the  results  as  rules 
that  may  be  applied  to  the  multilevel  view  to  derive  the  level-valid  view.  In  the  following 
discussion,  we  consider  each  view  q(R)  as  being  decomposed  into  the  unary  and  binary 
functions  available  in  a  relational  database.  In  this  approach,  the  “q”  consists  only  of 
“select/projecf  ’  operations,  while  the  “R”  may  represent  a  base  relation  or  one  formed  by 
a  Cartesian  product,  complement,  or  union. 

3.6.1.  The  Superset  View:  qi(R)  £  q3(Ri.) 

To  derive  a  level- valid  superset,  q3(R0,  of  a  multilevel  view,  qi(R),  we  must 
define  a  new  level-valid  view,  operating  only  on  data  at  level  L  or  below,  that  still 
contains  all  the  tuples  originally  in  qi(R).  The  first  thing  to  note  is  that,  while  qi(R) 
references  High  classified  information,  a  level-valid  view  cannot  actually  return  High 
classified  information.  Since  we  must  keep  all  tuples  that  satisfy  qi(R)  and  these  must  all 
be  classified  L  or  below,  qi  cannot  contain  “project”  clauses  referring  to  higher  classified 
attributes.  This  leads  to  the  first  rule: 

Superset  Rule  1:  For  Superset  Class  situations,  a  level- valid  constraint  is  not 
derivable  if  qi  contains  a  project  clause  returning  High  classified  attributes. 

Generally,  if  qi  does  not  contain  High  project  operations,  we  can  set  q3  =  qj,  but 
eliminate  select  clauses  referring  to  High  attributes.  Eliminating  select  clauses  does  not 
eliminate  any  tuples,  the  new  query  will  simply  have  fewer  restrictions  and  additional 
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tuples  will  satisfy  it.  This  is  why  q3  is  regarded  as  specifying  a  superset  of  the  original 
query,  qi. 

Superset  Rule  2:  Eliminate  select  clauses  relating  to  High  attributes. 

We  now  have  two  rules  explaining  how  q3  differs  from  qi.  We  must  also  know  if 
the  relation,  R,  needs  to  be  changed.  The  project  and  select  operations  apply  to  a  database 
relation.  There  are  three  additional  operations  that  may  be  used  to  define  that  relation: 
Cartesian  product;  union;  and  complementation. 

(a)  Cartesian  Product:  Consider  qi(R)  where  R  =  RlxRh  with  Rh  being  classified 
High.  Tuples  formed  via  Cartesian  products  will  contain  some  Low  classified  attributes 
and  some  High  classified  attributes.  However,  Since  q3  contains  no  clauses,  either  project 
or  select,  referring  to  High  classified  attributes,  the  view  q3(RLxRH)  cannot  contain  any 
tuples  with  High  classified  attributes.  The  tuples  satisfying  the  query  therefore  cannot 
contain  more  information  than  those  tuples  satisfying  q3(RO,  and  hence  could  be  formed 
directly  from  Rl-  It  is  possible  that  the  Cartesian  product  could  create  duplicate  tuples, 
but  these  would  be  eliminated  in  the  view,  so  q3(RLxRH)  C  q3(Ri.). 

(b)  Union:  Consider  qi(R)  where  R  =  RL  u  RH.  Suppose  that  qi(RL  u  RH)  = 
qi(Ri,)  u  qi(RH),  and  qi(Rn)  *  0-  Then  qi  contains  project  clauses  relating  to  High 
classified  attributes,  and  we  cannot  generate  a  superset  case. 

(c)  Complementation:  Since  Rl  and  Rh  are  disjoint,  they  have  no  tuples  in 
common.  Consider  first  qi(RL-RH)-  But  qi(RL-RH)  =  qi(Ru)  -  qi(Rn),  which  we  replace 
with:  q3(RL)  -  q3(Rn)-  So  q3(RL>  is  larger  than  qi(RL-RH),  and  we  have  a  superset  case. 
Therefore,  Rl-Rh  may  be  replaced  with  Rl  to  form  a  superset  case.  Consider  now  qi(RH 
-  Rl).  This  reduces  to:  q3(Rn)  -  q3(R0,  but  q3(RH)  =  0  (the  null  set),  so  “removing 
tuples”  is  not  defined,  and  we  must  set  q3(RH  -  Rl)  =  0-  So,  in  cases  other  than  High 
complementation,  the  High  relation  may  simply  be  removed  from  consideration. 

Superset  Rule  3: 

If  R  =  RL  x  Rh,  or  R  =  Rl  -  Rh,  set  R  =  RL. 

If  R  =  Rh  -  Rl,  set  q3(RL)  =  0. 

Similar  rules  may  be  derived  for  subset  views;  q3(RL)  C  qi(R) 

3.6.2.  Example  3: 

Assume  a  common  database  consisting  of  two  tables:  EMP  (employee,  classified 
L)  MGR  (managers,  classified  H).  The  constraint  “if  an  employee’s  manager  makes  less 
than  $50k  then  the  employee  must  make  less  than  $25k”  (i.e.  higher  paid  managers  are 
allowed  to  hire  higher  paid  subordinates).  Assume  that  the  employee  record  defines  the 
salary.  Salary,  and  the  employee’s  manager,  Mname.  Denote  as  T  the  “table” 
corresponding  to  the  single  employee  tuple,  t.  The  multilevel  constraint  for  addition  of  an 
employee  tuple  then  is: 
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M  =  (Select  t.Salary  from  T,  MGR  where  T.Mname  =  MGR.Mname  and 
(MGR.Salary<  $50K»  <  $25k 

Or,  by  separating  out  the  natural  join,  this  is  equivalent  to: 

M  -  (Select  t.Salary  from  ( T MGR  where  T.Mname  =  MGR.Mname)  where 
(MGR.Salary<  $50k)  <  $25k 

Since  we  are  dealing  with  an  identity  function,  it  may  be  considered  either  a 
subset  or  a  superset  case.  We  may  eliminate  the  natural  join  and  the  High  classified  select 
clause,  giving  the  level-valid  constraint  for  an  employee  tuple  as: 

L  =  (Select  t.Salary  from  T)  <  $25k 

Note  that  this  constraint  also  satisfies  the  tuple  deletion  conditions,  so  the 
database  does  not  have  to  be  checked  for  consistency  if  employees  making  less  than  $25k 
are  either  hired  or  fired. 

Although  the  set  of  rules  appears  like  a  complicated  and  disconnected  list  of 
special  cases  and  disconnected  rules,  in  reality  it  is  no  more  complicated  than  any  other 
algebraic  system.  The  process  of  generating  a  level-valid  constraint  is  similar  to  other 
algebraic  reduction  procedures.  Simply  apply  the  right  rule  at  the  right  time. 

4.  CONCLUSIONS 

We  have  shown  that  many  multilevel  integrity  constraints  can  be  transformed  into 
multiple  level-valid  constraints  whose  satisfaction  is  sufficient  to  ensure  that  the  original 
multilevel  constraint  is  also  satisfied.  The  level-valid  constraints  are  free  from  signaling 
channels. 

This  transformation  is  facilitated  by  devising  a  simple,  powerful,  yet  intuitive 
method  of  expressing  constraints  as  the  relationship  between  the  values  of  aggregate 
functions  applied  to  views.  In  many  cases  it  is  possible  to  transform  the  original 
multilevel  constraint  into  multiple  level-valid  constraints  whose  satisfaction  is  sufficient 
to  ensure  that  the  original  is  also  satisfied.  In  transforming  the  multilevel  constraint  we 
have  two  possibilities:  (1)  the  aggregate  function  remains  valid  if  applied  against  a  subset 
of  the  original  tuples  (i.e.  the  maximum  value  attained  in  a  set  will  be  at  least  as  great  as 
the  maximum  value  attained  in  any  subset)  or  (2)  the  aggregate  function  remains  valid  if 
applied  against  a  superset  of  the  original  tuples  (i.e.  the  maximum  value  attained  in  a  set 
will  be  no  greater  than  the  maximum  value  attained  in  any  superset). 

Within  this  general  solution,  we  can  actually  derive  level-valid  constraints  for  the 
common  database  operations  and  functions.  We  describe  the  procedures  for  generating 
the  needed  set  of  tuples  as  a  view  at  level  L  or  below,  having  the  desired  relationship  (that 
is,  being  either  a  subset  or  a  superset)  to  the  view  specified  in  the  constraint.  The 
generation  of  this  new  view  is  straightforward,  but  the  techniques  vary  depending  upon 
the  relational  algebra  operations  being  used. 

The  techniques  may  be  generalized  for  use  with  transactions,  or  constraints 
expressed  as  triggers,  not  simply  the  tuple  additions/deletions  considered  already.  These 
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new  level-valid  constraints  do  not  solve  the  entire  problem,  and  occasionally  tuple 
modifications  will  have  to  rely  upon  trusted  methods  as  are  commonly  used  in  current 
implementations.  However,  the  situation  is  never  more  complicated,  and  level-valid 
constraints  are  usually  simpler  and  more  straightforward  than  the  trusted  process 
technique. 
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Abstract 

We  give  in  this  work  an  answer  to  the  question  of  how 
real-life  confidentiality  can  be  introduced  to  an  open 
database  in  a  declarative  manner.  We  present  five 
forms  of  real-life  confidentiality ,  translate  them  in  the 
context  of  logic  and  show  that  only  two  forms  can  be 
brought  in  accord  with  databases  that  make  the 
Closed  World  Assumption.  These  two  forms ,  which 
correspond  to  real-life  situations  in  which  we  do  not 
want  to  admit  that  we  are  trying  to  keep  something 
secret ,  can  be  precisely  defined  as  distortions  of  the  da¬ 
tabase's  intended  model  The  main  result  of  this  work 
is  a  definition  of  a  database  with  unequivocal  static 
and  dynamic  semantics  that  supports  real-life  confi¬ 
dentiality  at  a  declarative  level  Two  of  its  properties 
are  that  we  never  encounter  polyinstantiation  and 
that  there  is  no  inference. 

1  Introduction 

Many  works  on  databases  commence  with  the  state¬ 
ment  that  a  database  is  generally  regarded  as  an 
image  of  a  given  section  of  the  real  world.  Relational 
and  logic-based  databases  are  defined  in  such  a  way 
that  their  components  correspond  to  many  impor¬ 
tant  elements  of  the  real-world  section. 

Attribute  values  of  a  tuple  or  terms  correspond 
to  names  that  can  be  assigned  to  entities  of  the  real- 
world  section.  A  relation  or  a  predicate  symbol  is 
used  to  express  a  simple  statement  on  one  or  more 
entities’  property  or  relationship.  A  tuple  or  a 
ground  atomic  formula  is  a  concrete  statement  on 
the  entities  named  in  it  And  the  state  of  the  data¬ 
base,  ie  a  finite  collection  of  tuples  or  ground  atomic 
formulae,  is  a  snapshot  of  the  state  of  the  proper¬ 
ties.  In  a  strict  sense,  the  truth  value  of  only  those 
tuples  which  are  contained  in  the  state  is  known  - 
the  truth  values  of  the  remaining  tuples  are  un¬ 
known.  This  situation,  however,  is  not  in  accord 


with  the  situation  in  many  real-world  sections.  To 
give  an  example,  if  a  train  at  a  particular  time  is  not 
listed  in  the  timetable,  then  everybody  knows  that 
there  is  no  train  at  this  time  and  if  an  item  is  not  list¬ 
ed  on  the  shipping  order,  then  everybody  knows 
that  it  is  not  shipped.  To  adapt  the  database  to  this 
real-life  situation,  Reiter  (1984)  introduced  and  for¬ 
malised  the  Closed  World  Assumption  (CWA), 
which  tells  us  that  a  tuple  is  false  if  it  is  not  in  the 
database  state.  Integrity  constraints,  ie  algebraic  ex¬ 
pressions  or  closed  formulae,  are  also  not  a  theoret¬ 
ical  invention  for  its  own  sake  but  a  reflection  of  ex¬ 
isting  invariants  and  conditions  of  the  real-world 
section. 

If  we  take  a  closer  look  at  a  database,  we  will  no¬ 
tice  that  great  care  has  been  taken  to  define  the 
above-mentioned  components  in  such  a  way  that, 
within  the  chosen  expressive  frame,  they  represent 
the  best  possible  copy  of  the  elements  of  the  real- 
world  section.  We  cannot  say  that  this  is  also  true  if 
we  take  a  look  at  confidentiality.  The  only  means  a 
database  system  offers  is  a  blurred  and  inadequate 
concept  of  rights.  It  is  blurred  because  the  right  to 
select  an  element  and  the  rights  to  insert,  delete 
and  update  elements  are  grouped  together.  But  the 
first  right  relates  to  confidentiality,  which  is  the  abil¬ 
ity  to  get  to  know  something,  and  the  remaining 
rights  relate  to  competence  and  powers,  which  is 
the  ability  to  do  something.  And  it  is  inadequate  be¬ 
cause  access  restriction  is  merely  an  often  neces¬ 
sary  tool  for  achieving  confidentiality  but  there  are 
only  a  few  situations  in  which  it  is  also  sufficient  In 
order  to  introduce  confidentiality  to  a  database  as  a 
sound  and  useful  concept,  we  must  first  investigate 
its  forms  in  the  real  life.  We  must  determine  what  do 
we  precisely  mean  and  want  to  achieve  when  we  say 
lX  should  be  kept  secret  from  B’\  we  must  investi¬ 
gate  the  ways  we  use  to  achieve  this  and  the  as- 
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sumptions  and  preconditions  on  which  the  ways 
rely.  And,  lastly,  we  must  find  out  which  of  the  forms 
and  ways  can  be  expressed  in  and  handled  by  a  rela¬ 
tional  or  logic-based  database  with  the  CWA 

Our  approach  is  based  on  the  following  observa¬ 
tion.  The  intended  state  of  an  open  real-world  sec¬ 
tion  (OWS)  is  reflected  in  the  intended  model  of  an 
open  database  (ODB).  A  user  who  has  access  to  the 
ODB  can  see  all  of  it  and  modify  it  according  to  his 
powers.  A  database  with  confidentiality  demands 
(CDB)  must  therefore  correspond  to  a  real-world 
section  with  confidentiality  demands  (CWS).  The 
introduction  of  confidentiality  into  the  OWS  implies 
that  the  intended  state  of  the  OWS  is  distorted  in 
front  of  a  user  from  whom  an  element  of  the  OWS 
should  be  kept  secret  -  the  OWS  still  exists,  but  the 
user  is  shown  a  CWS,  which  is  a  distorted  OWS.  To 
imitate  this  situation  in  databases,  we  must  distort 
the  intended  model  of  the  ODB  and  show  the  user  a 
CDB  such  that  the  intended  model  of  the  CDB  is  a 
distortion  of  the  intended  model  of  the  ODB. 

We  show  in  this  paper  that  there  are  three  possi¬ 
ble  kinds  of  distortions:  those  based  on  external 
conventions,  single-model  and  multi-model,  and 
that  these  distortions  can  be  derived  from  the  ways 
confidentiality  is  handled  in  the  daily  life.  We  also 
identify  invariants  of  the  ODB  which  cannot  be  dis¬ 
torted  for  if  we  do  it  the  result  can  no  longer  be 
called  a  database.  And,  lastly,  we  present  some  crite¬ 
ria  for  the  satisfiability  of  confidentiality  demands. 

The  first  kind  of  distortions  stems  from  the  ob¬ 
servation  that  if  somebody  is  looking  at  something 
he  does  not  know,  instead  of  telling  him  what  it  real¬ 
ly  is  we  can  tell  him  that  it  is  something  else.  This 
kind  does  not  require  any  changes  to  the  database 
for  we  only  distort  the  external  convention  of  the 
meaning  of  some  database  elements.  To  give  an  ex¬ 
ample,  suppose  there  is  a  relation  with  the  name 
hot_fields  the  intended  conventional  meaning  of 
which  is  secret  airfields.  If  a  user  is  unaware  of  this 
convention  and  we  want  to  keep  it  secret  from  him, 
we  can  tell  him  it  is  a  list  of  favourite  holiday  spots. 

Single-model  distortions  transform  the  ODB 
with  its  single  model  into  a  CDB  with  also  only  a  sin¬ 
gle  model.  In  real  life,  this  process  corresponds  to 
situations  in  which  we  do  not  want  to  admit  that  we 


are  trying  to  keep  something  secret.  We  present  the 
user  of  the  CDB  with  a  single  distorted  model  hop¬ 
ing  that  he  is  unable  to  notice  the  distorted  parts  of 
it.  Suppose  you  want  to  go  to  a  pub  this  evening  and 
the  person  who  asks  you  about  your  plans  today 
should  not  know  of  it,  so,  you  can  try  to  put  an  inno¬ 
cent  look  on  your  face  and  tell  him  that  you  go  to  the 
library.  This  kind  of  distortions  are  particularly  dif¬ 
ficult  to  realise  since  you  must  ensure  that  all  invar¬ 
iants  are  satisfied  and  the  users’  powers  are  not  vio¬ 
lated. 

Lastly,  multi-model  distortions  transform  the 
ODB  with  its  single  model  into  a  CDB  with  many 
models.  The  parallel  to  it  in  real  life  is  a  situation  in 
which  you  admit  that  you  have  a  secret  or  in  which 
you  pretend  that  you  really  do  not  know  the  answer 
to  a  question,  though  you  do.  The  problem  with  this 
kind  is  that,  by  definition,  a  database  with  the 
Closed  World  Assumption  always  has  a  single  mod¬ 
el*.  We  also  investigate  the  informal  and  formal 
sides  of  these  distortions  but  we  regard  them  as  in¬ 
compatible  with  our  database. 

In  today’s  databases  the  static  and  dynamic  se¬ 
mantics  and  integrity  constraints  have  a  clean  de¬ 
clarative  definition,  whereas  confidentiality  is  most 
often  reduced  to  low-level  operational  access  rules. 
This  situation  makes  it  hard,  if  not  impossible,  to 
conduct  formal  examinations  and  derive  properties 
capable  of  proof  with  respect  to  confidentiality.  The 
main  contribution  of  this  work  is  a  declarative  defi¬ 
nition  of  confidentiality  in  databases  with  the  CWA 
The  definition  relies  on  the  notion  of  a  model  which 
is  a  precise  and  well-understood  element  of  mathe¬ 
matical  logic.  We  also  show  that  this  is  not  a  superfi¬ 
cial  definition  -  it  reflects  exactly  two  forms  of  confi¬ 
dentiality  of  the  real  life  and,  therefore,  it  is  useful 
and  easy  to  understand.  It  enables  us  to  state  confi¬ 
dentiality  demands  in  the  same  declarative  manner 
as,  eg,  we  translate  invariants  of  the  real-world  sec¬ 
tion  into  integrity  constraints  and  we  can  formally 
investigate  their  satisfiability.  The  approach  is  unde¬ 
niably  more  complex  than  a  couple  of  access  rules, 

*  If  the  application  of  the  CWA  to  a  database 
renders  it  inconsistent  or  yields  several  models, 
then  the  CWA  is  regarded  is  incompatible  to  the  da¬ 
tabase  and  is  not  applied  to  it 
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yet  our  secrets  in  the  daily,  real  life  prove  that  we 
are  well  able  to  handle  it. 

The  subsequent  section  presents  a  formal  defini¬ 
tion  of  a  database  and  an  extensive  example  that  il¬ 
lustrates  the  formal  notions.  Section  three  focuses 
on  previous  works  in  this  area.  In  section  four  we 
introduce  some  extensions  to  an  open  database 
which  are  necessary  preliminaries  to  the  introduc¬ 
tion  of  confidentiality.  The  central  part  of  this  work, 
section  five,  discusses  the  effect  of  the  various 
forms  of  confidentiality  on  the  structure  of  databas¬ 
es.  In  the  last  section  a  conclusion  briefly  summaris¬ 
es  our  findings  and  presents  a  short  outlook. 

2  Basic  definitions 

In  this  section  we  give  a  formal  definition  of  an  open 
database  and  illustrate  it  with  a  comprehensive  ex¬ 
ample. 

An  alphabet  21  is  a  non-empty  and  finite  set  of 
symbols,  such  that  any  string  of  2fs  elements  has  a 
unique  decomposition  into  2fs  elements.  2J*  de¬ 
notes  the  set  of  strings  of  finite  length  of  elements  of 
21.  Let  F  =  21*  be  the  set  of  function  symbols, 
Pc  21*  a  finite  set  of  predicate  symbols,  and 
pF  :  F ^  {0}  and  p  :  N0the  functions  deter¬ 

mining  the  arity  of  the  symbols.  Then 
2  =  (21  ,P,p) 

is  a  database  signature.  Let  V  be  an  infinite  set  of 
variables.  Then  T(2)  =  F  U  V  is  the  set  of  terms 
over  the  signature  2.  TG(2)  =  F  is  the  subset  of 
ground  terms.  The  set  of  atomic  formulae  over  2  is 

At 2)  =  |  P  E  P,p(P)  =  fly 

and  Ag(Z)  is  the  subset  of  ground  atomic  formulae. 
With  a  E  A( 2) ,  a  is  a  positive  literal  and  ->a  a  neg¬ 
ative  literal.  The  first  order  language  over  the  signa¬ 
ture  2  is  the  smallest  set  L(Z)  with  the  following 
properties:  A(2)cL(2);  if  <p,tpEL( 2),  then 
(<P)  v  for)  E  L(2) ;  if  <p  E  I(Z) ,  then  -(*>)  E  L(2) ; 
if  <p  E  U 2)  and  XEV,  then  VX:<pE  L( 2) .  L0(2) 
is  the  subset  of  closed  formulae,  viz,  all  variables  of 
a  <p  E  L0(2)  are  quantified.  A  normal  clause  is  a 
closed  formula  a  <-X1  A  ...  A  Xn  in  which  all  varia¬ 
bles  are  assumed  to  be  universally  quantified, 
a  E  A{ 2)  is  the  clause’s  head  and  X1  A  ...  A  Xn  ,  a 


conjunction  of  literals,  its  body.  A  clause  is  range-re¬ 
stricted  if  any  variable  that  occurs  in  the  clause  oc¬ 
curs  also  in  a  positive  literal  in  its  body. 
CR( 2)  c  L0( 2)  is  the  set  of  range-restricted  clauses 
over  2. 

Let  and  Q  be  sets  such  that  there  is  a  cof  E  Q 
a)F  :  F  ^ 

and  for  each  p  E  P ,  p(p)  =  n  ,  there  is  a  Op  E  Q 
a)p  :  ->  {True,  False} 

Then  itf(2)  =  (®,  Q)  is  an  interpretation  for  the 
signature  2.  Alternative  notations  for  restrictions  to 
k{  2)  =  ($,Q): 

•  for  ground  atomic  formulae: 

M( 2)  :  Ag(Z)  {True,  False} 

•  for  closed  formulae: 

M0( 2)  :  L0(2)  ->  {True,  False} . 
k(Z)  is  a  model  of  4>,  iVf(2)  E  Mod(<F) ,  $  c  L0(2) , 
if  V<p  E  :  Af0(2)(v?)  =  True .  (Some  works  on  da¬ 
tabases  define  a  model  as 

M-1(E)(True)  c  Ac(2) .) 

M(Z)  =  (S),  Q)  is  a  Herbrand-interpretation  or  a 
Herbrand-model  if  5)  =  TG(2)  and  a>F  =  id. 
W  c  L0(Z)  is  a  logical  consequence  of  <I>  c  L0(Z) , 
t=  W ,  if  Mod(3>)  c  Mod(W) . 

We  assume  that  the  intended  semantics  of  a  set 
<5  c  L0(2)  is  defined  by  its  completion*  with  re¬ 
spect  to  2,  comp(<b,  2) . 

Let  2  be  a  database  signature,  C  c  L0(2) , 
Mod(C)  ^  0 ,  a  finite  set  of  closed  formulae  over  2 
and  7  c  CR(Z)  a  finite  set  of  range-restricted  claus¬ 
es  over  2  such  that  comp(7, 2)  t=  C.t  Then 
D  =  (2,  C,  7) 

is  a  logic-based  database  with  completion  seman¬ 
tics.  2  defines  the  database  language,  C  is  the  set  of 
integrity  constraints,  7  is  a  valid  present  state  and 
the  intended  semantics  of  7  is  defined  by  the  unique 
Herbrand-model  M( 2)  of  comp(7, 2) . 

A  transaction  T  is  a  finite  sequence  of  finite  sets 
of  ground  atomic  formulae,  which  are  annotated  for 
insertion  or  deletion,  ie 

T=  ((Aj,  #j), (An,^w)) 

*  Cf,  eg,  Das  (1992)  or  Cremers/Griefahn/ 
Hinze  (1994). 

f  This  definition  ensures  that  the  integrity  con¬ 
straints  are  satisfiable  and  that  the  completion  has  a 
unique  Herbrand-model. 
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such  that  Ai  c  AC(Z.)  and  #,•  e  { INS,  DEL}  for  all 
1  <  i  <  n .  The  operational  semantics  of  T,  ie  the 
application  of  T  to  7  is  the  successive  insertion  or 
deletion  of  T’s  sets,  which  yields  a  set  /'. 

I0  =  I 

=  f  huAk  +  v  if#*  +  i  =  INS 
*  +  1  \h^k  +  v  if^  +  i  =  DEL 

*'  =  4 

If  7'  is  valid,  then  T  is  accepted  and  said  to  be 
valid  and  7'  becomes  the  present  state  of  D;  other¬ 
wise  Tis  rejected  and  the  state  remains  unaltered.  T 
is  a  singleton-transaction  if  T  =  ((71, #))  and 
\A\  =  1 .  Let  Tbe  valid  and  M'(Z)  the  model  of  7'. 
The  declarative  semantics  of  T,  ie  the  effect  of  T  on 
M(2 )  is  a  partitioned  set  r  =  r^Ur(,  r  c Ac(2) , 
such  that 

•  M(2)(a)  =  True  and  M'(Z)(a)  =  False ,  for 
all  a  S  t6  , 

•  M(£)(a)  =  False  and  M'(T)(a)  =  True,  for 
all  a  G  zt ,  and 

•  M(Z)(a)  =  M’(Z.)(a)  for  all  a  <=  Ac(E)\z . 

We  now  illustrate  these  definitions  with  a  relational 
example. 

EXAMPLE  1  Suppose  we  have  a  database  with  the 
following  three  relations: 


Starships 

Starship 

Enterprise 

Voyager 

Missions 

Starship 

Destination 

Objective 

Enterprise 

Asgard 

Fun 

Voyager 

Midgard 

Aid 

Freight 

Starship 

Cargo 

Enterprise 

Beer 

Voyager 

Rice 

Voyager 

Corn 

The  primary  key  of  the  Missions  relation  is  its  first 
attribute  and  both  attributes  of  the  Freight  relation 


constitute  its  primary  key.*  There  are  foreign  keys 
from  Missions  to  Starships  and  from  Freight  to  Star- 
ships  on  the  Starship  attribute. 

Then: 

•  21  is  a  subset  of  the  printable  ASCII  symbols 
and  F  the  set  of  strings  of  finite  length 

•  P  —  {Starships,  Missions,  Freight}, 
p(Starships)  =  1,  p(Missions)  =  3, 
p(Freight)  =  2 

•  a  =  Freight(Voyager,  Beer)  is  a  ground  atomic 
formula  and  also  a  range-restricted  clause 

•  2>  =  Tg(Z)  =  F,  and 

^  —  {wf) 0,1  Starships’  ^Missions’  ^ Freight  ^  w^th 


(Op  -  id 

"Starships  :  $  ■*  {True>  False> 
x  k>  False 


"Missions  :  -  <True’  False> 

( x,y,z )  f->  True 


"Freight :  -*  {True>  False> 


(x,y) 


True,  if  (x,y)  =  (Voyager,  Rice)  or 
(x,y)  =  (Voyager,  Gold) 
False,  otherwise 


define  a  Herbrand-interpretation^  for 
2  =  (21,  P,p) ,  the  signature  of  the  database. 

•  The  database  state  is  the  set 
7  =  {Starships(Enterprise), 
Starships(Voyager) , 

Missions(Enterprise,  Asgard,  Fun), 

Missions  (Voyager,  Midgard,  Aid), 
Freight(Enterprise,  Beer), 

Freight(Voyager,  Rice), 

Freight(Voyager,  Corn)} 

•  The  intended  model 

M(Z) :  A(L)  -*  {True,  False} 
of  the  state  7  assigns  the  truth  value  True  to  all 
elements  of  7  and  False  to  all  other  tuples. 

*  Note  that  the  primary  key  of  the  Starships  rela¬ 
tion  is  implicitly  given  for  it  has  only  one  attribute 
and  7  is  a  set,  ie  there  are  no  duplicates. 

f  But  note  that  it  is  not  a  model  of  the  state. 
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•  T  =  (({Freight(Enterprise,  Coke) },  INS))  is  an 
accepted  singleton-transaction;  its  effect  is 
r  =  z6  U  r(  with  z6  =  0  and 
r(  =  {Freight (Enterprise,  Coke)}.  The  previ¬ 
ous  model  has  assigned  the  truth  value  False  to 
Freight(Enterprise,  Coke),  the  present  one  as¬ 
signs  to  it  True. 

3  Previous  and  related  work 
In  SQL  only  the  GRANT/REVOKE  SELECT  state¬ 
ments,  which  apply  only  to  relations,  support  confi¬ 
dentiality.  Formally,  the  open  database 
D  =  (2,  C,/)  with  2  =  (21,  P,p)  has  a  set  of  rela¬ 
tions,  P.  If  a  user  u  does  not  possess  the  SELECT 
right  to  some  relations,  then  there  is  a  database 

Du  =  with  =  (®’Pu’Pj  such 

that  PUQP  and  the  remaining  components  of  Du 
are  restrictions  of  the  components  of  D  to  the  ele¬ 
ments  of  Pu .  Informally,  we  use  this  method  to  sim¬ 
ply  lie  to  the  user:  if  an  excluded  relation  is  a  base 
relation,  then  we  lie  to  him  about  the  extent  of  the 
real-world  section  which  is  known  to  the  database 
and  if  the  excluded  relation  is  a  view  with  an  obvi¬ 
ous  connection  to  a  base  relation,  then  we  lie  to  him 
about  the  truth  value  of  the  withheld  tuples  (they 
are  true  in  the  intended  model  of  /  but  false  in  that 
of  Iu ).  Note  that  D  and  Du  are  not  two  independent 
databases.  Du  is  a  distorted  copy  of  D,  which  corre¬ 
sponds  to  a  distorted  image  of  the  real-world  sec¬ 
tion  and  any  change  applied  to  Du  is  immediately 
propagated  to  D.  The  SQEapproach  has  two  disad¬ 
vantages.  Firstly,  there  is  no  way  of  storing  in  Du 
tuples  that  are  not  in  D,  ie,  we  cannot  set  a  tuple’s 
truth  value  to  False  in  D  and  to  True  in  Du .  And, 
secondly,  we  have  not  found  any  paper  or  manual, 
which  tells  you  how  to  define  Pu  in  such  a  way  that 
the  restriction  of  D  to  Du  results  in  a  valid  database 
Du  and  that  a  transaction  accepted  by  Du  will  not 
be  rejected  by  D,  ie,  that  Du  retains  the  static  and 
dynamic  semantics  of  a  database. 

Most  other  algebraic  approaches  are  based  on 
SeaView,  a  multi-level  relational  data  model  intro¬ 
duced  by  Denning  et  al  (1987).  It  assumes  that 
there  is  an  open  database  D  which  is  associated 
with  the  highest  security  level  of  a  lattice  of  security 
levels  and  that  a  database  D;  is  associated  with  any 


other  security  level  l.  Since  each  Dl  is  a  restriction 
of  D,  the  approach  is  in  fact  similar  to  that  of  SQL. 
The  only  difference  is  that  in  addition  to  reducing  P, 
the  set  of  relations,  SeaView  is  also  able  to  reduce  I. 
Thus,  SeaView  simply  lies  to  the  user  in  the  same 
way  as  SQL  does.  But  whereas  SQL  provides  a  clear 
informal  concept  and  formal  definition  of  its  notion 
of  confidentiality,  SeaView  does  not.  The  idea  to 
bring  NULL-values  in  connection  with  confidentiali¬ 
ty  and  the  idea  that  polyinstantiation  -  a  phenome¬ 
non  invented  to  justify  a  flawed  design  -  is  natural 
and  inevitable  resulted  in  situations  in  which  the 
meaning  of  confidentiality  is  unclear.  The  obvious 
consequence  of  these  facts  is  that  SeaView  also  in¬ 
herits  all  disadvantages  of  SQL  and  adds  to  it  a  pile 
of  its  own  problems. 

There  are  several  works,  eg  Sicherman/de 
Jonge/van  de  Riet  (1983),  Morgenstern  (1987)  and 
Bonatti/Kraus/Subrahmanian  (1992),  which  re¬ 
gard  a  formula  as  a  unit  of  protection  and  a  formu¬ 
la’s  confidentiality  is  defined  as  non-derivability. 
Whereas  derivability  is  a  unique  notion,  non-deriva- 
bility  can  be  formalised  in  three  ways.  Suppose  that 
a  formula  <p  S  Z/2)  should  be  kept  secret  from  the 
user  «.  Then,  firstly,  <p  is  not  derivable  in  Du  if  ip 
cannot  be  expressed  in  the  language  of  Du ,  ie,  if 
<p  £  L(2B) .  Or,  secondly,  if  <p  is  in  D,  then  it  is  not  in 
Du  or  vice  versa,  ie,  if  the  truth  value  of  <p  in  Du  is 
opposite  to  that  in  D,  ie  M(Z){<p)  =  -> <Mu(Zu)(<p ) . 
Or,  lastly,  if  all  true  statements,  which  comprise  <p, 
can  be  only  reduced  to  a  non-singleton  OR-state- 
ment,  ie,  to  a  formula  <p  v  xp  with  <p  *  ip.  This  situ¬ 
ation  implies  that  Du  does  not  have  a  unique  intend¬ 
ed  model  but  many  and  there  are  two  models  M*u 
and  Nfu  such  that  Af^Xyi)  =  ^B(2B)(p).This 
last  interpretation  is  chosen  by  Sicherman/de 
Jonge/van  de  Riet  (1983)  and  Bonatti/Kraus/Sub¬ 
rahmanian  (1992);  Morgenstern  (1987)  does  not 
tackle  the  choices. 

Based  on  the  conviction  that  standard  logic  is  in¬ 
adequate,  Thuraisingham  (1991)  and  Thuraising- 
ham  (1992)  attempt  to  formalise  the  rules  and  prop¬ 
erties  of  mandatory  access  control  models*  in 
NTML,  a  non-monotonic  logic,  which,  however,  has 


*  Cf,  eg,  Landwehr  (1981). 
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been  shown  to  be  not  sound.  The  main  step  in 
NTML  is  the  assignment  of  a  security  level  to  all  el¬ 
ements  of  the  signature  and  to  all  formulae  of  D. 

=  (2 lu,Pu,pu)  is  determined  by  the  user's  cur¬ 
rent  security  level  and  the  components  of  Du  are 
restrictions  of  the  components  of  D  to  the  elements 
°f  =  {^uyPuyPu)' 

4  Users  and  powers  in  open  databases 
Before  we  can  investigate  the  forms  of  confidential¬ 
ity,  we  must  realise  that  the  ability  to  keep  a  unit  of 
protection  secret  from  a  user  is  limited  by  two  fun¬ 
damental  factors: 

•  the  user's  powers  to  change  the  present  state, 
which  must  be  respected 

•  the  user's  ability  to  learn  about  the  unit's  cur¬ 
rent  state  or  existence  without  asking  the  data¬ 
base 

Therefore,  the  first  extension  to  an  open  data¬ 
base  with  respect  to  confidentiality  is  the  inclusion 
of  these  concepts. 

Let  D  -  (2,  C,  I)  be  an  open  database.  We  as¬ 
sume  that* 

•  there  is  a  finite  set  U  —  {uly  of  users 

who  have  legitimate  access  to  D 

•  for  each  u  G  U  there  is  a  set  Ru  Q  AG(2)  that 
reflects  the  user's  powers  in  the  real-world  sec¬ 
tion,  which  means  that  a  transaction  T  with  the 
effect  r  executed  by  u 

■  is  rejected  if  r  is  not  a  subset  of  Ru ,  and 
•  must  be  accepted  by  D  if  r  is  a  subset  of  Ru 
and  does  not  violate  the  integrity  con¬ 
straints 

We  say  that  T  is  authorised  if  r  is  a  subset  of 

*.• 

•  for  each  u  GU  there  is  a  set  Ku  £  Aq(Z)  that 
reflects  the  user’s  specific  knowledge  on  the 
real-world  section,  ie  his  ability  to  learn  about 
the  current  state  or  existence  of  some  units 
without  asking  the  database 

Then 

D  =  (H,C,I,U,{Ru}uBU,{Ku}ueU)  (1) 

is  an  open  extended  database.* 

The  rights  Ru  determine  the  transactions  user  « 
is  authorised  to  execute.  While  the  decision  on  a 


transaction’s  validity  is  made  by  the  integrity  con¬ 
straints,  an  organisation’s  or  an  application’s  securi¬ 
ty  policy  is  solely  responsible  for  the  granting  and 
the  revocation  of  an  authorisation.  This  means  that 
we  must  distinguish  the  reasons  because  of  which  a 
transaction  can  be  rejected.  If  it  is  because  of  a  vio¬ 
lation  of  the  state’s  validity,  then  the  integrity  con¬ 
straints  make  the  reasons  explicit,  and,  at  the  same 
time,  provide  the  justification  -  both  are  visible  and 
comprehensible  to  the  user.  If  it  is  for  lack  of  author¬ 
isation,  then  the  user  can  neither  find  the  reasons 
nor  the  justification  within  the  database.  The  securi¬ 
ty  policy  is  only  reflected  in  the  rights  -  it  is  not  stat¬ 
ed  there.  Thus  if  a  user  is  puzzled  about  a  missing 
right,  then  it  is  not  the  database,  but  the  persons 
who  set  up  the  security  policy  that  are  responsible 
for  providing  a  satisfactory  explanation.  Since  this 
work  is  on  confidentiality,  the  consequences  of  fail¬ 
ing  to  do  so  can  be  neglected  from  our  viewpoint  as 
long  as  no  information  must  be  kept  secret  from  the 
user.  Otherwise,  this  behaviour  may  well  affect  a  us¬ 
er’s  trustworthiness  in  the  negative. 

The  purpose  of  the  set  Ku  is  that  its  elements 
cannot  be  kept  secret  from  u.  The  question  of  how 
to  determine  Ku  precisely  has,  of  course,  no  single 
true  answer.  But  the  semantics  of  the  powers,  Ru , 
tells  us  that  the  least  a  user  can  know  about  the  real- 
world  section  is  what  he  has  arranged  or  is  able  to 
do  so,  ie,  Ru  is  a  lower  bound  on  Ku . 

Assumption  1  RuqKu  always  holds. 

5  Confidentiality  in  databases 
This  chapter  investigates  the  transition  from  an 
open  database  (ODB),  which  corresponds  to  an 
open  real-world  section,  to  a  database  with  confiden¬ 
tiality  demands  (CDB) ,  which  corresponds  to  a  real- 
world  section  with  confidentiality  demands. 

5.1  Distortion  of  the  intended  external 
convention 

The  algebraic  and  logic-based  theory  of  databases 
is  not  concerned  with  the  question  of  how  does  a 


*  Note  that  there  are  no  confidentiality  de¬ 
mands,  ie,  the  users  are  still  allowed  to  know  every¬ 
thing. 
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database  user  know  the  real-life  meaning  of  the  rela¬ 
tion  names  and  the  attribute  values,  ie  the  elements 
of  the  signature.  As  long  as  the  database  is  open, 
this  question  is,  admittedly,  of  little  avail  to  the  theo¬ 
ries.  However,  the  situation  changes  as  soon  as  we 
introduce  confidentiality. 

The  actual  correspondence  between  the  ele¬ 
ments  of  the  real-world  section  and  the  elements  of 
the  signature  is  established  in  two  steps.  Firstly,  the 
persons  who  communicate  with  the  real-world  sec¬ 
tion  are  identified  with  the  users  who  communicate 
with  the  database.  Secondly,  the  real-world  meaning 
of  an  element  of  the  signature  is  fixed  in  the  intend¬ 
ed  external  convention,  a  convention  intelligible 
and  known  to  all  legitimate  users. 

In  open  databases  the  real-world  objects  and 
their  properties  are  taken  to  be  indistinguishable 
from  their  names  in  the  signature  of  which  the 
users  have  an  implicit  understanding.  One  could  ob¬ 
ject  that  if  this  level  of  abstraction  was  questioned, 
then  one  could  proceed  ad  infinitum,  and  the  ironic 
end  would  be  the  situation  in  which  one  is  not  able 
to  refer  to  a  real-world  object  in  a  conversation  but 
to  point  with  a  finger  to  this  object  itself.  In  practice, 
however,  this  argument  misses  the  nature  of  codes, 
watchwords  and  other  secret  arrangements.  Their 
usefulness  relies  on  the  fact  that  a  group  of  people  is 
in  the  know  of  only  a  single  additional  level  of  indi¬ 
rection  with  respect  to  some  names'  natural-lan¬ 
guage  semantics.  The  sentence  Tonight  we  go  to 
the  pub’  gains  a  different  meaning  for  the  members 
of  a  gang  who,  in  order  to  hide  their  intentions,  have 
agreed  to  denote  a  bank  as  a  pub.  To  take  this  situa¬ 
tion  into  account,  we  assume  that  a  signature  is  a 
syntactical  object  with  semantic  intentions  in  re¬ 
spect  of  its  real-world  meaning,  which  are  stated  in 
an  explicit  convention. 

Let  £  be  the  intended  external  convention  of  the 
signature*  2  =  (2t,  P,p) .  If  an  element  of  2  should 
be  kept  secret  from  a  user  u>  we  can  present  to  him 
£w ,  a  distortion  of  £. 

Example  2  Suppose  that 


*  Note  that  a  convention  does  not  apply  to  the  tu¬ 
ples’  truth  values.  All  elements  of  the  database  state 
are  taken  as  true  and  all  remaining  ones  as  false. 


•  hot_fields  is  a  relation,  ie  an  element  of  Py  and 
its  intended  external  convention  is 
£(hotjields)  =  ‘is  a  secret  airfield’ 

•  red  E  Tc{ 2)  is  an  attribute  value  and 
£(red)  =  ‘alert  condition  red’ 

If  a  user  is  unaware  of  the  intended  meaning  of 
these  symbols  and  we  would  like  to  keep  it  secret 
from  him,  then  we  can  offer  him  the  following  exter¬ 
nal  convention  £M  ,  which  is  a  distortion  of  £: 

•  £M  (hot_fields)  =  ‘is  a  favourite  holiday  spot* 

•  £M  (red)  =  ‘the  colour  red’ 

First  of  all,  we  do  not  gain  any  relevant  insight  if 
we  try  to  formalise  £  since  it  is  the  final  level  of  de¬ 
scribing  the  meaning  of  an  image  of  a  real-world 
section.  For  that  reason  the  database  has  no  way  of 
influencing  the  intended  external  convention.  On 
the  one  hand,  this  makes  this  distortion  quite  sim¬ 
ple  to  apply  because  the  database  does  not  need  to 
be  changed  in  anyway.  On  the  other,  its  applicability 
is  limited  to  only  a  few  situations.  Assumption  1  tells 
us  that  the  user  has  no  update  rights  to  tuples  with 
a  distorted  convention.  Otherwise,  we  were  in  for  a 
home-made  sabotage.  Suppose  that  user  u  of  Exam¬ 
ple  2  changes  red  to  green  because  he  wants  to  give 
something  a  fresh  look  -  this  is  a,  possibly  unintend¬ 
ed,  distortion  of  the  open  database  with  respect  to 
the  intended  external  convention  and  it  confuses  all 
users  who  rely  on  it  It  is  also  useless  in  many  other 
situations.  It  may  be  only  of  some  help  if  the  user  is 
a  guest  who  somehow  sees  a  part  of  the  database. 

Since  distortions  of  the  intended  external  con¬ 
vention  cannot  be  influenced  by  the  database  we  do 
not  examine  it  further  and  assume  from  now  on  that 
all  users  u  E  U  have  a  uniform  intended  external 
convention. 

5.2  Multi-model  distortions 

Multi-model  distortions  are  a  formalisation  of  two 

situations: 

i)  somebody  pretends  not  to  know  the  answer  to 
a  question  though  he  does 

ii)  somebody  admits  to  have  a  secret 

The  intention  in  both  cases  is  to  construct  a 
CWS  by  introducing  a  certain  degree  of  blur  into 
the  OWS. 

An  example  of  the  first  case  is  the  question 
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‘Where  does  this  plane  go  to?’  and  the  answer  to  it  ‘I 
really  do  not  know’.  Since  you  know  or  see  that  the 
plane  has  left,  this  answer  tells  you  that  the  plane 
may  go  to  any  airport  within  its  reach  and  on  which 
it  can  land.  Suppose  that  the  meaning  of  the  predi¬ 
cate  W  is  ‘is  the  destination  of  this  plane’,  then,  for¬ 
mally,  this  answer  can  be  represented  as  the  follow¬ 
ing  finite  disjunction: 

W(Rome)  v  W( Paris)  v  ...  v  W(London) 
if  Rome,  Paris  and  London  qualify  as  possible  desti¬ 
nations.  We  can  describe  this  situation  with  respect 
to  the  open  database  with  its  unique  intended  model 
M(2)  as  follows.  Suppose  that  Rome  is  the  intended 
destination.  Then  the  CDB  for  the  user  u,  who  asks 
the  question,  is  constructed  by  replacing  M(X)  with 
a  finite  set  of  models  T?a(2)  such  that 
i)  The  CDB  claims  that  is  the  smallest  set 

of  its  models 

it)  |<Tlu(E)|  >  1 ,  ie  the  state  of  some  elements  of 
the  real-world  section  is  unknown  and  there  is 
no  unique  intended  model 

iii)  M(E)  €  ,  ie  the  intended  destination  is 

among  the  possible  destinations 

iv)  There  is  at  least  one  £  T?U(Z)  such  that 
Af^(2)(W(Rome))  =  False,  ie  at  least  one 
choice  tells  you  that  Rome  is  not  the  intended 
destination 

An  example  of  the  second  case  is  the  question 
‘How  much  do  you  earn?’  and  the  answer  to  it  ‘I 
know  it  but  I  will  not  tell  if.  Informally,  you  are  told 
that  the  amount  of  the  salary  is  secret  Formally,  the 
answer  can  still  be  represented  as  a  finite  disjunc¬ 
tion  since  the  lowest  amount  is  fixed  by  law  and  the 
highest  amount  by  common  sense.  The  formal  rep¬ 
resentation  of  this  case  in  the  database  is  identical 
to  that  of  the  first  case  with  the  exception  of  points 
(i)  and  (ii): 

i)  There  is  an  ODB  with  a  unique  intended  model 
and  the  CDB  is  a  distortion  thereof 

ii)  |2TC„(2)|  >  1 ,  ie  the  state  of  some  elements  of 
the  real-world  section  is  deliberately  blurred 

Of  these  two  cases  the  first  one  is  not  applicable 
to  our  database  because  it  violates  its  definition.  The 
statement  that  the  OWS  cannot  be  represented 
more  precisely  than  by  a  non-singleton  set  of  mod¬ 
els,  T?u(2) ,  contradicts  the  CWA,  which,  if  compati¬ 


ble  to  the  database,  always  yields  a  unique  intended 
model. 

The  second  case  has  several  problems.  Firstly, 
in  order  to  give  an  indefinite  answer,  the  semantics 
of  the  database  has  to  be  extended.  Secondly,  there 
are  no  satisfactory  approaches  to  the  representation 
of  and  its  operational  treatment  Whereas 

these  problems  can  be  solved,  its  main  flaw  is 
shown  by  Sicherman/de  Jonge/van  de  Riet  (1983). 
They  use  a  censor  who  takes  into  account  the  user- 
knowledge  and  the  dialogue  up  to  that  time  and  who 
decides  on  the  database’s  answer.  The  censor,  who 
never  lies,  gives  the  indefinite  answer  if  he  believes 
that  the  user  will  be  able  to  deduct  the  secret  with 
the  help  of  a  precise  yes/no-answer.  The  authors 
demonstrate  that  this  can  still  be  of  little  avail  since 
the  user  can  make  use  of  the  censor’s  reasoning  in 
his  own  one  and  discover  the  secret 

Thus,  we  conclude,  multi-model  distortions  can¬ 
not  be  used  to  introduce  confidentiality  to  an  open 
database. 

5.3  Single-model  distortions 
Let  us  now  turn  our  attention  to  situations  in  which 
confidentiality  is  understood  in  the  sense  that  we 
would  also  like  to  keep  the  fact  confidential  that  we 
have  a  secret 

5.3.1  Distortion  of  the  truth  values 
An  example  of  such  a  situation  is  the  question 
Where  does  this  plane  go  to?’  and  the  answer  to  it 
To  London’,  though  you  know  that  Rome  is  its  in¬ 
tended  destination.  Since  you  also  want  to  keep  it 
secret  that  your  answer  is  a  lie  you  must  take  many 
additional  precautions.  Firstly,  you  must  ensure  that 
your  answer  complies  with  the  general  knowledge 
on  the  real-world  section,  eg,  that  this  plane  can  in¬ 
deed  fly  to  and  land  in  London.  Secondly,  you  must 
ensure  that  the  person  who  asks  the  question  is  un¬ 
able  to  modify  your  secret  and  any  information  re¬ 
lated  to  it,  eg,  that  he  cannot  order  this  plane  to 
Paris  or  add  a  cargo  of  grapes,  which  never  arrives 
in  London.  And,  lastly,  when  confidentiality  is  no 
longer  desired  you  must  inform  this  person  of  its 
true  destination,  eg  Rome,  and  remove  the  lie  used 
to  cover  it,  eg  London. 
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This  situation  has  the  following  formal  corre¬ 
spondence.  Suppose  that  the  user  u  asks  the  ques¬ 
tion.  Then  you  present  to  u  a  CWS  with  the  follow¬ 
ing  properties: 

•  You  pretend  in  front  of  u  that  the  statement 
This  plane  flies  to  Rome'  has  the  opposite  truth 
value  in  the  CWS  as  in  the  OWS 

•  In  order  to  satisfy  the  integrity  constraint  ‘Eve¬ 
ry  plane  has  a  destination’  you  use  an  alias, 
London,  and  pretend  in  front  of  u  that  the  state¬ 
ment  This  plane  flies  to  London’  has  the  oppo¬ 
site  truth  value  in  the  CWS  as  in  the  OWS 

•  You  must  check  that  u  does  not  have  the  pow¬ 
ers  to  alter  the  plane’s  destination  and  cargo 

•  You  must  record  that  the  statement  This  plane 
flies  to  Rome'  should  be  kept  secret  in  front  of 
u  and  that  the  statement  This  plane  flies  to 
London*  is  only  used  as  an  alias  for  the  first 
statement,  so  that  when  the  truth  value  of  the 
first  statement  in  the  CWS  is  adjusted  to  that  in 
the  OWS,  the  same  must  be  done  for  the  alias. 

With  this  in  mind,  it  is  easy  to  translate  the  situ¬ 
ation  in  the  context  of  our  database.  Recall  that  the 
intended  model  of  the  ODB 

D  =  (Z,C,I,U,{Ru}ueV,{Ku}ueU) 
is  the  mapping 

M(Z)  :  AC(Z)  -*  {True,  False}  (2) 

which  assigns  a  truth  value  to  all  ground  atomic  for¬ 
mulae,  ie  to  all  possible  tuples.  We  now  construct 
the  CDB  Du  =  (Za,  Cu,  Iu)  with 

MU(ZU) :  AC(2U)  -»  {True,  False} 

Let  a  be  the  tuple  which  should  be  kept  secret 
Then: 

i)  set 

Mu(Zu)(a)  =  -M(S)(«) 
ie  set  the  truth  value  of  a  in  the  CDB  to  the  op¬ 
posite  of  its  truth  value  in  the  ODB 

ii)  if  there  are  some  integrity  constraints 

if>p  ipm  €=  Cu  which  are  no  longer  satisfied 
due  to  step  (i),  try  to  find  one  or  more  aliases 
/?j,  such  that  ipp  ..., ipm  are  satisfied  if 

we  set 

Muau)0i)  =  -M(Z)03,.) 
for  all  i  =  1, ...,  n 

tii)  check  that  a,  (ip  ...,pn  £  Ru  to  ensure  that  u 
cannot  destroy  our  secret 


iv)  if  u  can  now  execute  a  valid  and  authorised 
transaction  with  respect  to  Du  which,  however, 
will  be  rejected  by  D,  prevent  it  -  try  to  find  one 
or  more  aliases  7p  ...,  yk  such  that,  if  we  set 

Muau)(7i)  =  -M(Z)(y,.) 
for  all  i  =  1, ...,  k ,  then  every  valid  and  au¬ 
thorised  transaction  with  respect  to  Du  is  also 
accepted  by  D 

v)  to  record  all  these  distortions  we  must  intro¬ 
duce  an  alias-log  Pi 

a)  insert  into/5 

P(DU,  a,  secret,  {/3p  ...,pn,yv .... y*}) 

b)  if  some  of  the  aliases 

...,<5ze  {pp  ...,P„,Yp  ...,yk} 
have  required  further  aliases  for  them¬ 
selves,  then  insert  into  P for  all  i  =  1, I 

P(Du,di,  alias,  {d'j . d;.}) 

There  are  no  changes  to  the  signature  ZK  and  to 
the  integrity  constraints  Cu ,  ie  ZM  =  I,  Cu  =  C 
and  Du  =  (Z,  C,  Iu)  As  long  as  we  have  a  relation¬ 
al  database,  there  is  a  simple  correspondence  be¬ 
tween  the  content  of  the  state  Iu  and  the  intended 
model  MU(Z)  • 

Thus,  we  have  constructed  a  function  which  rep¬ 
resents  the  intended  model  of  the  CDB  Du , 

MU(Z) :  Ag(2)  -»  {True,  False}  (3) 

which  assigns  to  all  tuples  that  do  not  occur  in  the 
alias-log  P  the  same  truth  value  as  (2),  the  intended 
model  of  the  CDB,  does  and  which  assigns  to  all  tu¬ 
ples  that  occur  in  P,  ie,  which  should  be  kept  secret 
from  u  or  are  a  consequence  of  this  confidentiality 
demand,  the  opposite  truth  value  than  (2)  does.  In 
this  sense  we  can  say  that  (3)  is  a  distortion  of  (2) 
and  the  parameter  of  the  distortion  is  the  assign¬ 
ment  of  truth  values. 

To  draw  a  parallel  to  real  life,  we  hide  a  secret  by 
telling  some  more  lies  and  pretend  that  everything 
is  in  perfect  order  -  at  the  same  time  we  are  well 
aware  of  the  possibility  that  other  people  behave  in 
die  same  manner  in  front  of  us. 

This  type  of  confidentiality  applies  only  to 
ground  atomic  formulae,  ie  tuples  -  we  cannot 
change  the  truth  value  of  a  term,  ie  an  attribute  val¬ 
ue,  or  a  a  relation  because  they,  simply,  do  not  have 
truth  values.  To  include  this  type  of  confidentiality 
in  our  database  we  only  have  to  include  the  alias-log 
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P  into  it.  Thus,  the  open  extended  database  with 
users  and  powers 

D  =  (2  ,C,I,U,{Ru}ueU,{Ku}ueU) 
now  becomes  a  database  with  confidentiality 
D  =  (2  ,C,I,U,{Ru}ueU,{Ku}uSU,P)  (4) 

To  construct  a  particular  distorted  database  Du 
we  take  the  model  of  D ,  apply  the  distortions  re¬ 
corded  in  the  alias-log  P  to  it  and  then  translate  the 
distortions  of  the  model  to  distortions  of  the  state  of 

Du- 

EXAMPLE  3  Let  us  take  a  look  at  Example  1  and  let 
us  say  that  it  represents  the  open  database  D.  Sup¬ 
pose  that «  is  a  user  and  the  tuple  Missions(Enter- 
prise,  Asgard,  Fun)  should  be  kept  secret  from  him. 
We  now  construct  the  distorted  database 
Du  =  (2,  C,  Iu)  with  the  distorted  model  MU(Z) . 
The  Starships  relation  remains  unaltered,  ie,  Iu 


comprises 

Starships 

Starship 

Enterprise 

Voyager 

To  reverse  the  truth  value  of  the  secret  tuple  in 
Du  we,  firstly,  present  to  u  the  following  Missions 
relation: 


Missions 

Starship 

Destination 

Objective 

Voyager 

Midgard 

Aid 

We  can  skip  step  (ii)  since  all  integrity  con¬ 
straints  remain  valid.  Suppose  that  the  secret  tuple 
is  not  in  the  update-rights  of  u.  Now  at  step  four,  we 
notice  that  u  has  the  powers  to  schedule  the  Enter¬ 
prise  to  Muspelheim.  If  he  decides  to  insert  the 
tuple  Missions(Enterprise,  Muspelheim,  Re¬ 
search),  ie,  the  Missions  relation  in  Du  would  be  as 
follows 


Missions 

Starship 

Destination 

Objective 

Enterprise 

Muspelheim 

Research 

Voyager 

Midgard 

Aid 

then  we  have  a  violation  of  the  dynamic  semantics 
of  Du .  The  transaction  of  u  is  authorised  and  valid 
with  respect  to  «  and,  consequently,  must  be  accept¬ 
ed  by  Du .  Since  D  and  Du  are  not  two  separate  da¬ 
tabases  but  Du  is  only  a  distortion  of  D,  the  transac¬ 
tion  is  immediately  propagated  to  D  and,  obviously, 
it  will  be  rejected  by  D  -  an  action  for  which  u  can¬ 
not  find  any  explanation  in  Du .  To  avoid  this  situa¬ 
tion  we  notice  that  u  has  no  update  rights  on  tuples 
that  comprise  Nifelheim.  So,  as  an  alias  for  the  se¬ 
cret  tuple  Missions  (Enterprise,  Asgard,  Fun) ,  we  in¬ 
sert  into  the  Missions  relation  the  tuple  Mis¬ 
sions  (Enterprise,  Nifelheim,  Maintenance).  The 
final  Missions  relation  in  Du  is  then: 


Missions 

Starship 

Destin. 

Objective 

Enterprise 

Nifelheim 

Maintenance 

Voyager 

Midgard 

Aid 

If  u  now  tries  to  insert  his  tuple,  this  will  be  re¬ 
jected  and  he  can  find  an  explanation  for  it  in  Du :  a 
violation  of  the  primary  key.  To  keep  the  example 
short  we  do  not  extend  our  consideration  to  the 
Freight  relation. 

Suppose  that  we  have  flattened  the  alias-log  to  a 
relation,  then,  lastly,  we  insert  into  it  the  tuple 
P(DU .Missions (Enterprise, Asgard, Fun),  secret, 
Missions(Enterprise,  Nifelheim,  Maintenance)),  k 

5.3.2  Distortion  of  the  domain 
An  apparent  shortcoming  of  the  above-defined  type 
of  confidentiality  is  that  we  are  unable  to  keep  the 
existence  of,  eg,  the  starship  Enterprise  secret  Sup¬ 
pose  that  in  the  first  step  we  remove  the  tuple  Star- 
ships  (Enterprise)  from  the  Starships  relation  in  the 
distorted  database.  But  then,  in  step  four,  we  notice 
that  we  need  an  alias  to  preserve  the  database  se¬ 
mantics  but  there  is  none.  Well,  one  can  object  that 
we  can  remove  all  tuples  that  comprise  the  name 
Enterprise  from  the  user’s  update  rights.  But  if  he 
has  the  powers  to  buy  new  starships  how  do  we  jus¬ 
tify  in  front  of  him  the  fact  that  he  is  not  allowed  to 
name  a  new  starship  Enterprise?  This  problem  is 
quite  important  in  practice  since,  eg,  there  may  be  a 
public  hangar  for  the  Voyager  starship  and  a  secret 
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hangar  for  the  Enterprise.  To  distinguish  this  type 
of  confidentiality  from  the  previous  one,  we  must 
note  that  the  object  of  confidentiality  of  the  previous 
type  is  the  truth  value  of  a  statement  Here,  the  ob¬ 
ject  of  confidentiality  is  the  existence  of  objects  and 
properties. 

A  solution  to  this  problem,  structured  name- 
spaces,  is  presented  in  Spalka/Cremers  (1997). 
Here  we  show  only  how  structured  name-spaces 
can  be  interpreted  as  a  distortion  of  the  intended 
model. 

We  recall  that  real-world  objects  correspond  to 
attribute  values  of  a  tuple  or  terms  and  properties  to 
relations  or  predicates.  In  order  to  keep  the  exist- 
ence  of  an  object  or  a  relation  secret  the  database 
must  pretend  that  it  is  not  an  element  of  the  real- 
world  section,  ie,  when  asked  about  it  a  possible  an¬ 
swer  is  ‘I  do  not  know  what  you  are  talking  about’.  If 
we  again  take  a  look  at  the  intended  model 
M(Z) :  Aq(Y)  ->  (True,  False} 
then  we  note  that  the  previous  type  of  confidentiali¬ 
ty  modifies  the  value  of  this  function  at  certain 
points.  Now,  to  pretend  that  some  objects  or  proper¬ 
ties  are  unknown,  this  function  must  become  unde¬ 
fined  at  all  points,  which  comprise  the  secret  object 
or  property.  The  obvious  way  to  achieve  it  is  to  re¬ 
move  these  points  from  the  function’s  domain 
AgC£)  .  Since  AG(Z)  is  determined  by  the  signature 
2,  we  can  modify  it  only  by  modifying  Z.  Some  of 
the  previous  works  have  shown  that  it  is  quite  easy 
to  present  to  a  user  u  a  database  with  a  distorted 
signature  ZM  =  (21  ,Pu,pu)  from  which  some  rela¬ 
tions  are  removed,  ie  Pu  c  P.  In  this  case  the  user 
is  not  told  that,  eg,  there  is  a  relation  that  stores  a 
cargo’s  value,  but  he  can  still  ask  about  Enterprise. 
To  prevent  him  from  doing  this  we  must  structure 
the  database’s  flat  name-space.  To  give  an  example, 
a  file  system  can  store  two  files  with  same  name  if 
they  are  in  different  directories.  Here,  the  full  path¬ 
name  of  the  directory  serves  as  a  name-space  selec¬ 
tor  and  the  name  of  the  file  is  a  local  name  within 
the  selected  name-space. 

Spalka/Cremers  (1997)  come  to  the  conclusion 
that  following  modifications  to  Z  =  (2l,P,p),  the 
signature,  are  necessary  to  obtain  a  database  with 
structured  name-spaces: 


•  21*  is  regarded  as  a  universal  name-space 

•  There  is  a  new  set  E  of  name-space  selectors 

•  N  =  E  x  21*  is  the  new  global  universal 
name-space  and  (a,  b)  £  E  x  21*  an  element  of 
it 

•  The  sets  of  terms  and  predicates  are  now  de¬ 
fined  over  N  (and  not  over  21* ) 

•  For  each  user  uG  U  there  is  a  set  EUQE  of 
name-space  selectors  available  to  u,  which  de¬ 
fines  his  personal  universal  name-space 

Nu  =  U 

eSEu 

At  a  first  glance,  we  must  extend  our  database 
with  two  components:  E  and  the  set  of  all  Eu .  How¬ 
ever,  Spalka/Cremers  (1997)  show  that  if  confiden¬ 
tiality  is  the  purpose  for  using  structured  name- 
spaces,  then  setting 

E  =  V(U)  (5) 

the  power-set  of  U,  already  offers  maximum  flexibil¬ 
ity.*  We  therefore  assume  (5)  and  give  the  final  def¬ 
inition  of  a  database  with  confidentiality: 

D=  V,C,I,U,{Ru}ueU,{Ku}u£U,P,  (6) 

We  just  need  one  more  word  on  P.  The  intended 
model  of  D  is  now  the  function 

M(Z) :  Ac( Z)  -»  {True,  False}  (7) 

such  that  AC(Z)  is  defined  over  N,  and  the  intended 
model  of  a  distorted  database  Du  is  now  the  func¬ 
tion 

M(2„) :  Ac{ Z„)  -  {True,  False }  (8) 

such  that  Aq(Eu)  is  defined  over  Nu .  If  we  begin 
the  construction  of  (8)  by  reducing  (7)  to  Aq(Hu)  , 
then  we  need  to  store  in  the  alias-log  P  only  the  re¬ 
versed  truth  values  with  respect  to  Ac{ Zu) . 
EXAMPLE  4  Let  us  again  take  a  look  at  Example  1. 
Suppose  that  the  starship  Enterprise  is  hidden  in  a 
secret  hangar  and  should  be  kept  secret  from  the 
user  «.  Firstly,  we  introduce  a  structure  on  the  data¬ 
base’s  flat  name-space.  We  set 

E  =  %>(U)  =  {0,{w}} 

and  Eu  =  {{«}}.  Then  the  Starships  relation  re- 


*  It  is  also  sufficient  to  model  multi-level  struc¬ 
tures. 
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ceives  the  following  representation  in  D: 


({«},  Starships) 

Starship 

(0 ,  Enterprise) 

({«},  Voyager) 

Since  Nu  =  { w }  x  21* ,  the  reduction  of  (7)  to 
(8)  with  respect  to  Nu  yields  the  following  Star- 
ships  relation  in  Du : 


({ u },  Starships) 

Starship 

({«},  Voyager) 

Now,  if  u  buys  a  new  starship  and  decides  to 
name  it  Enterprise  he  can  enter  without  any  prob¬ 
lems  the  tuple  ({«},  Starships)  ({«},  Enterprise)  into 
the  database. 

Suppose  we  wish  to  keep  the  Freight  relation  se¬ 
cret  from  u,  then  we  only  need  to  assign  to  it  a 
name-space  selector  which  is  unavailable  to  u,  ie,  we 
set  (0 ,  Freight),  k 

5.3.3  Some  remarks 

In  (6)  we  have  arrived  at  a  database  that  supports 
two  forms  of  confidentiality.  It  is  a  well  defined  data¬ 
base  in  the  following  sense: 

i)  Its  static  semantics  is  identical  to  that  of  an 
open  database,  viz,  both  the  open  database  and 
any  distortion  thereof  have  a  unique  intended 
model 

ii)  Its  dynamic  semantics  is  a  natural  restriction  of 
that  of  an  open  database  since  a  transaction 
must  be  both  valid  and  authorised  to  be  accept¬ 
ed* 

Hi)  It  defines  the  meaning  of  confidentiality  in  a 
precise  declarative  manner  and  there  is  a  clear 
correspondence  to  the  real  life 
iv)  As  in  real  life  it  rejects  confidentiality  demands 
that  are  recognised  to  be  not  satisfiable 

*  However,  it  is  much  harder  to  define  and  com¬ 
pute  the  effect  of  a  transaction  if  the  users  are  em¬ 
bedded  in  a  hierarchy  of  groups.  We  will  soon  re¬ 
port  on  this  problem  in  a  paper. 


A  consequence  of  point  (i)  is  that  we  do  not  even 
need  to  think  of  polyinstantiation.  Since  we  have  a 
clear  distinction  between  the  ODB  and  any  CDB, 
we  always  precisely  know  the  intended  state  of  af¬ 
fairs  in  the  OWS  and  we  have  full  control  of  the  dis¬ 
tortions  in  any  CWS. 

A  consequence  of  the  points  (i),  (ii)  and  (iv)  is 
that  we  also  do  not  need  to  think  of  inference.  With 
respect  to  our  approach,  inference  can  be  defined  as 
the  ability  of  a  user  of  a  CDB  to  discover  one  or 
more  distortions  and,  thus,  infer  its  intended  state 
in  the  ODB.  However,  the  way  we  have  constructed 
(6)  precludes  exactly  this  possibility.  Well,  of 
course,  the  user  of  the  CDB  may  know  somebody 
who  knows  something  about  a  distorted  element  - 
that’s  life,  but  what  is  more  important  is  that  our  da¬ 
tabase  cannot  do  anything  about  it  It  can  take  into 
consideration  only  those  elements  of  which  it 
knows  -  and  these  are  precisely  stated  in  (6). 

We  have  identified  five  forms  of  confidentiality 
and  shown  that  one  of  it  cannot  be  influenced  by  the 
database,  two  of  them  are  not  compatible  with  the 
CWA  and  the  final  two  forms  can  be  integrated  in  a 
database.  There  is  probably  no  formal  proof  that 
there  are  no  other  forms  of  confidentiality  but  if  we 
identify  the  semantics  of  a  database  with  its  intend¬ 
ed  model,  then  there  are  no  other  ways  of  distorting 
a  function.  The  only  additional  distortion  we  can 
apply  is  to  include  alias-predicates  in  the  distorted 
domain,  ie,  the  CDB  comprises  relations  that  do  not 
exist  However,  we  do  not  regard  this  distortion  as  a 
form  of  confidentiality  but  only  as  a  tool  for  the  sat¬ 
isfaction  of  confidentiality  demands.* 

Lastly,  this  paper  gives  only  a  definition  of  a  data¬ 
base.  The  important  question  of  how  we  determine 
whether  a  confidentiality  demand  is  satisfiable  and, 
if  it  is,  how  we  compute  the  necessary  distortions,  is 
left  open.  We  will  present  an  answer  to  it  in  the  near 
future. 

6  Conclusion 

The  motivation  for  this  work  is  the  question  of  how 


f  We  presently  investigate  whether  there  are  sit¬ 
uations  in  which  the  inclusion  of  false  predicates  is 
necessary. 
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we  can  introduce  real-life  confidentiality  in  an  open 
database  in  a  declarative  manner.  In  a  first  step  we 
have  introduced  users  and  their  powers  in  the  open 
database  and  argued  that  the  powers  users  have  in 
real  life  must  also  be  respected  by  the  database, 
which  implies  that  there  is  a  set  of  clearly  not  satis- 
fiable  confidentiality  demands.  We  have  then  pre¬ 
sented  five  forms  of  real-life  confidentiality,  we  have 
translated  them  in  the  context  of  logic  and  shown 
that  only  two  forms  can  be  brought  in  accord  with 
the  Closed  World  Assumption  in  our  database. 
These  two  forms,  which  correspond  to  real-life  situ¬ 
ations  in  which  we  do  not  want  to  admit  that  we  are 
trying  to  keep  something  secret,  can  be  precisely 
defined  as  single-model  distortions  of  the  data¬ 
base’s  intended  model.  Our  view  that  confidentiality 
must  be  seen  as  a  distortion  of  an  open  world-sec¬ 
tion  has  led  us  to  a  database  with  confidentiality, 
which  is  an  extension  to  open  databases,  ie,  it  pos¬ 
sesses  unequivocal  static  and  dynamic  semantics.  A 
consequence  of  this  and  some  other  properties  is 
that  we  never  encounter  polyinstantiation  and  that 
there  is  no  inference.  The  most  important  result  of 
this  work  is  the  final  definition  of  a  database  with 
confidentiality.  We  have  shown  that  the  components 
of  this  database  are  necessary  in  order  to  introduce 
real-life  confidentiality  to  an  open  database. 

In  the  near  future  we  will  present  more  details 
on  the  definition  and  execution  of  transactions  in 
our  database  and  some  methods  for  the  enforce¬ 
ment  of  confidentiality  demands. 

Lastly,  we  would  like  to  make  a  remark  on  a 
problem  that  is  closely  related  to  confidentiality, 
though  not  an  issue  of  the  database  design.  In  a  da¬ 
tabase  that  supports  confidentiality,  users  and  pro¬ 
grams  can  receive  incomplete  or  wrong  informa¬ 
tion.  This  distorted  information  is  often  used  in  fur¬ 
ther  decisions.  We  believe  that  at  this  stage  it  is  the 
responsibility  of  users  who  state  confidentiality  de¬ 
mands  to  contemplate  on  their  negative  conse¬ 
quences  and  implications. 
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Abstract 

This  paper  shows  how  the  simplified  event  calcu¬ 
lus  (SEC)  may  be  used  as  the  basis  for  representing 
security  models  for  discretionary  access  control  when 
access  rights  may  be  expressed  as  holding  for  limited 
periods  of  time. 

The  approach  presented  here  involves  using  normal 
clause  logic  to  write  a  set  of  axioms  to  represent  a 
specific  security  model  with  time  constrained  autho¬ 
risations .  These  model  specific  axioms  are  combined 
with  a  set  of  rules  which  represent  the  core  axiom  of 
the  SEC  and  a  set  of  ground  atomic  assertions  which 
represent  a  history  of  security  events  which  affect  a 
database.  In  this  framework ,  a  subject’s  request  to 
access  a  database  object  is  allowed  only  if  the  access 
request  can  be  proved  to  hold  from  the  resulting  ax- 
iomatisation. 

An  example  security  model  is  presented  to  demon¬ 
strate  the  approach ,  extensions  to  this  model  are  out¬ 
lined  and  some  important  practical  issues  are  dis¬ 
cussed. 

1  Introduction 

The  need  to  protect  a  database  against  unautho¬ 
rised  access  has  long  been  recognised  as  important  [7]. 
However,  whilst  languages  for  expressing  access  rights 
and  methods  for  deciding  questions  of  authorisation 
have  been  supported  in  commercial  database  manage¬ 
ment  systems  for  some  time,  more  powerful  means  for 
expressing  security  information  are  increasingly  being 
demanded.  One  such  demand  is  for  access  control 
methods  which  permit  privileges  on  database  objects 
to  be  granted  to  subjects  for  limited  periods  of  time 
[18]. 

When  access  rights  are  only  allowed  for  a  certain 
duration  they  are  automatically  removed  on  the  expi¬ 
ration  of  the  interval  of  time  for  which  the  rights  were 
initially  permitted.  The  facility  which  enables  access 
to  be  specified  as  lasting  for  a  restricted  interval  of 
time  gives  the  grantor  of  a  right  a  good  deal  of  con¬ 
trol  over  the  permissions  they  give  to  grantees  and 


restricts  the  scope  the  latter  have  for  compromising 
the  security  of  the  data  contained  in  a  database. 

There  are  many  practical  situations  in  which  time- 
constrained  access  rights  are  required.  In  our  own 
computing  department,  for  instance,  it  has  proved 
necessary  to  grant  privileges  on  resources  to  students 
for  different  periods  of  time  depending  on  such  things 
as  their  enrolment  status  and  the  type  of  course  they 
are  attending.  Thus  far,  this  facility  has  been  sup¬ 
ported  via  ad-hoc,  low-level  routines  ;  a  more  general, 
higher-level  approach  is,  however,  needed. 

This  paper  presents  a  method  which  may  be  used 
for  implementing  a  system  for  discretionary  access 
control  when  access  rights  may  be  restricted  by  time. 
As  such,  our  work  addresses  similar  issues  to  those 
considered  in  Bertino  et  ai.  [3].  The  approach  we 
adopt  is,  however,  quite  different  and  has  certain  dis¬ 
tinct  advantages. 

In  [3],  a  language  is  described  which  enables  users 
to  write  temporal  authorisations  and  derivation  rules. 
The  former  are  used  to  explicitly  record  the  rights 
individuals  have  been  granted  on  objects  by  whom 
and  for  how  long.  The  latter  are  used  to  derive  the 
privileges  which  are  implied  by  the  temporal  autho¬ 
risations.  Both  the  temporal  authorisations  and  the 
derivation  rules  may  be  expressed  as  holding  for  a 
particular  interval  of  time. 

Rather  than  providing  a  specific  language  for  users 
to  express  their  security  information,  in  our  treatment 
a  security  administrator  chooses  a  security  model  to 
implement  and  formulates  this  model  in  the  simplified 
event  calculus  (SEC)  [12].  Moreover,  the  notion  of  an 
event,  rather  than  an  interval  of  time,  is  central  in  our 
approach. 

We  argue  that  the  expressive  power  of  the  SEC 
provides  a  security  officer  with  considerable  scope  for 
representing  various  security  models  which  support 
the  specification  of  time-constrained  privileges.  This 
scope  is  achieved  by  treating  security  actions  as  con¬ 
stants  in  rules  which  are  written  in  clausal  form  logic 
to  describe  the  consequences  of  a  security  event  be- 
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ing  performed  on  a  database.  The  use  of  clausal  form 
logic,  on  which  the  SEC  and  our  approach  is  based, 
makes  it  possible  for  users  to  express  their  security 
requirements  in  a  clear  and  concise  way.  Moreover, 
this  formalisation  may  be  regarded  as  an  executable 
specification  which  may  be  verified,  informally  with 
prospective  end-users  and  formally  by  proving  prop¬ 
erties  of  the  specification,  prior  to  implementation. 

Our  approach  has  the  additional  attraction  of  en¬ 
abling  users  to  easily  express  authorisations  by  using  a 
set  of  ground  atomic  binary  relations.  A  simple  front- 
end  may  be  straightforwardly  implemented  to  further 
ease  the  burden  of  representing  security  information. 

The  rest  of  this  paper  is  organised  in  the  following 
way.  In  Section  2,  a  brief  overview  of  the  simplified 
event  calculus  is  presented.  In  Section  3,  the  details 
of  the  event-based  specification  of  security  informa¬ 
tion  are  given.  In  Section  4,  our  use  of  the  simplified 
event  calculus  to  represent  a  particular  security  model 
with  temporal  authorisations  is  outlined.  In  Section  5, 
theoretical  and  practical  issues  are  addressed  and,  in 
Section  6,  various  extensions  to  our  example  security 
model  are  discussed.  In  Section  7,  some  conclusions 
are  drawn  and  suggestions  are  made  for  further  work. 

2  The  Simplified  Event  Calculus 
(SEC) 

The  original  event  calculus  [8]  consists  of  a  num¬ 
ber  of  general  axioms,  expressed  in  terms  of  Horn 
clauses  augmented  with  negation  as  failure  [4],  which 
are  intended  to  be  used  for  knowledge  representation 
in  situations  where  reasoning  about  time  and  events 
is  required. 

The  basic  idea  is  that  the  general  axioms  of  the 
event  calculus  be  combined  with  a  set  of  domain  spe¬ 
cific  axioms,  which  define  the  initiation  and  termi¬ 
nation  of  relationships,  and  a  description  of  events 
which  have  occurred  in  the  world  a  database  purports 
to  describe.  From  this  set  of  axioms  and  a  descrip¬ 
tion  of  events  the  consequences  of  those  events  may 
be  derived  together  with  the  periods  of  time  for  which 
these  consequences  hold. 

The  simplified  event  calculus,  as  its  name  sug¬ 
gests,  is  a  restricted  form  of  the  event  calculus  which 
nonetheless  has  proved  to  be  useful  for  treating  a  num¬ 
ber  of  practical  problems  ([5],  [8],  [16]). 

The  SEC  only  permits  forward  persistence  and  is 
based  on  the  simplifying  assumption  that  complete 
information  exists  about  events,  including  the  times 
at  which  events  occur.  Under  this  assumption,  a  sin¬ 
gle  persistence  axiom  is  all  that  is  required  to  specify 
that  an  initiated  relationship,  JR,  continues  to  persist 


until  an  event  occurs  to  terminate  it.  The  core  axiom 
of  the  SEC,  CO  (say),  which  captures  this  notion  may 
be  expressed  thus  (where  -i  denotes  a  chosen  form  of 
negation  and  <  is  an  “earlier  than”  relation)  : 

holdsat(R,T)  <— 

happens  (El,  Tl)} 
initiates  (Elf  R)y 
T1  <  T, 

->3 E2,  T2 
[happens  (E2t  T2), 
terminates  (E2,R),T1  <  T2] 

More  fully,  CO  expresses  that  a  relationship  R  holds 
at  a  time  point  T  if  an  event  El  happened  which  ini¬ 
tiated  R  (ie.  made  R  true)  at  an  earlier  point  in  time 
T1  and  no  intervening  event  E2  has  terminated  R  (ie. 
made  R  false)  subsequent  to  its  initiation. 

Notice  that  for  CO ,  and  henceforth,  terms  which 
appear  in  the  upper  case  denote  variables. 

An  example  of  the  type  of  domain  specific  rules 
which  are  used  to  define  the  initiates  and  terminates 
predicates  appearing  in  CO  is  given  in  Section  4.  Be¬ 
fore  presenting  these  rules,  however,  we  consider  first 
the  representation  of  a  history  of  security  events  per¬ 
formed  on  a  database. 

3  Event  Descriptions  and  Authorisa¬ 
tion  Histories 

To  record  the  fact  that  a  security  event  has  taken 
place,  the  notion  of  a  security  event  description  is 
used.  A  security  event  description  consists  of  a  set 
of  ground  assertions  which,  as  the  name  implies,  de¬ 
scribes  the  occurrence  of  an  event  which  has  taken 
place  and  which  is  relevant  to  the  security  of  a 
database.  To  see  what  is  involved  in  representing 
these  events,  suppose  that  Bob  creates  a  database 
object  ol  on  1/1/99  and  takes  read  and  write  access 
rights  on  ol.  This  event,  eO  (say),  may  be  represented 
by  the  following  event  description  : 

happens  (eO,  1/1/99) } 
act  (e  0f  create), 
creator  ( e0}  bob ), 
object(eOfOl), 
mode  (eOf  read)  j 
mode  (eO,  write). 

In  keeping  with  the  language  used  in  the  event  cal¬ 
culus,  the  choice  of  predicate  names  in  the  assertions 
appearing  in  the  event  description  for  eO  are  influ¬ 
enced  by  the  work  on  semantic  cases  ([6],  [13]).  Any 
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constant  which  appears  as  an  argument  in  one  of  these 
predicates  is  one  of :  an  event,  a  time,  a  database  sub¬ 
ject,  a  group  identifier,  a  database  object  or  an  action 
which  is  permissible  in  the  security  model. 

In  the  event  eO,  create  is  the  action  which  is  per¬ 
formed.  Now,  whilst  a  subject  clearly  needs  to  be 
able  to  do  more  that  just  create  objects,  the  precise 
set  of  actions  a  subject  may  perform  will  depend  on 
the  choice  of  security  model  to  be  implemented. 

The  actions  upon  which  the  example  security 
model  given  in  Section  4  is  based  are  those  which  are 
included  in  the  set,  A={create,  grant,  grantgroup, 
revokeright,  revokegroupright,  destroy}  ;  the  access 
modes  considered  are  those  in  the  set,  M={read, 
write}.  That  is,  in  this  security  model,  subjects  may 
create  and  destroy  objects  and  may  grant  and  revoke 
some  or  all  of  the  read  and  write  privileges  individ¬ 
uals  or  groups  of  individuals  may  have  on  database 
objects. 

Notice  that  the  security  event  descriptions  for  all  of 
the  actions  in  A  will  be  similar  in  form  to  the  event 
description  for  eO.  Whilst  the  predicate  names  and 
constants  will  differ,  a  security  event  description  will 
always  be  represented  using  a  set  of  ground  binary 
relations.  A  simple  front-end  may  be  used  to  both 
assist  users  in  describing  security  events  and  to  ensure 
that  security  event  descriptions  are  syntactically  and 
semantically  meaningful. 

To  see  more  fully  what  is  involved  in  describing  a 
history  of  events  affecting  database  security,  suppose 
that  Bob  has  created  the  database  object,  ol,  and 
consider  the  following  narrative  : 

On  2/1/99  Bob  grants  John  write  access 
on  ol  until  5/1/99  and  read  access  until 
20/6/99.  On  15/4/99,  Bob  grants  Sue  read 
and  write  privileges  on  ol  indefinitely  into 
the  future.  On  25/4/99,  Bob  grants  every 
member  of  the  Sales  department  read  access 
to  ol  until  1/6/99.  Sue’s  write  privilege  on 
ol  is  removed,  by  Bob,  on  20/5/99. 

The  corresponding  set  of  event  descriptions  de¬ 
scribing  the  narrative  above  (in  which  ei,  where  i  is  a 
natural  number,  denotes  an  event)  is  as  follows  : 

happens(el,2/l  /99 ), 
act(el, grant), 
grantee(el,john ), 
objectfel ,ol) , 
mode  (el,  write), 
stop(el,  5/1/99). 


happens  ( e2, 2/1  /99 ), 
act  (e2,  grant), 
grantee( e2,john), 
object(e2,ol), 
mode  (e2, read), 
stop(e2, 20/6/99). 

happens  ( e3, 15/4/99 ), 
act  (e3,  grant), 
grantee  ( e3,sue ), 
object(e3,ol), 
mode  (e3,  read), 
mode  (e3, write). 

happens  ( e4, 25/4/99 ), 
act( e4,  grantgroup ), 
grantee  ( e4,  sales ), 
object  (e4fol ), 
mode  (e4, read), 
stop(e4fl/6/99). 

happens  ( e5, 20/5/99 ), 
act( e5 , revokeright) , 
revokee(e5,sue), 
object  (e5,ol ), 
mode( e5, write ). 

A  set  of  security  event  descriptions  is  recorded  as 
part  of  the  information  which  is  maintained  in  the 
database  to  be  used  for  access  control.  In  the  exam¬ 
ple  security  model  which  we  consider,  only  the  cre¬ 
ator  of  a  database  object,  O,  can  grant  and  remove 
access  rights  and  decide  the  period  of  time  for  which 
rights  are  allowed  on  the  object.  As  such,  an  event  de¬ 
scription  is  only  permissible  for  O  if  it  is  asserted  by 
the  creator  of  O.  A  validation  procedure  for  security 
event  descriptions  ensures  that  the  specifier  of  such  a 
description  for  O  is  always  O’s  creator. 

Henceforth,  we  will  refer  to  a  set  of  security  event 
descriptions,  like  the  one  above,  as  an  authorisation 
history . 

Notice  that,  in  our  example  security  model,  it  is 
the  grant  and  grantgroup  operations  which  have  a 
temporal  component  to  them.  That  is,  rights  may 
be  specified  as  being  granted  for  a  limited  period  of 
time.  Not  surprisingly,  the  removal  of  a  privilege,  P, 
from  a  subject,  S,  on  an  object,  O,  at  a  time,  T,  pre¬ 
vents  S  gaining  P  access  to  O  unless  and  until  S  is 
granted  the  privilege  P  at  some  time  point  which  is 
subsequent  to  T. 

An  access  right  is  assumed  to  hold  from  the  point 
in  time  at  which  the  event  which  grants  the  access 
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actually  happens.  The  difference  between  the  time  in 
a  happens(e,t)  fact  and  a  stop(e,tl)  fact  (where  t  < 
tl)  is  the  interval  of  time  for  which  the  right,  granted 
in  the  event  e,  is  permitted  to  hold  for  the  subject(s) 
and  object  specified  in  a  security  event  description. 
As  our  example  authorisation  history  demonstrates, 
if  a  stop  time  is  not  associated  with  a  grant  then  the 
right  which  is  granted  is  assumed  to  be  permitted  in¬ 
definitely  into  the  future.  Conversely,  if  a  stop  time  is 
associated  with  a  grant  then  that  specifies  the  maxi¬ 
mum  future  time  point  up  until  which  a  privilege  is  to 
hold.  The  grantor  of  a  privilege  has  the  option  of  ter¬ 
minating  this  privilege  earlier  than  the  maximal  time 
by  using  a  revoke  operation  from  A. 

4  Formulating  a  security  model  in  the 
SEC 

As  we  have  said,  there  are  two  sets  of  rules  which 
are  important  in  our  approach.  One  set  of  rules  is 
needed  to  represent  the  axiom,  CO ,  of  the  SEC  ;  the 
other  set  is  needed  to  define  the  initiation  and  ter¬ 
mination  of  the  properties  of  interest  in  the  specific 
security  model,  with  time  constrained  access  rights, 
to  be  implemented. 

To  simulate  the  CO  axiom  the  following  three  rules 
may  be  used  : 

(Cl) 

holds  ( access  (S,P,0))  <— 

happens  (E,T), 

initiates  (E,  access( S,P,0) ), 

not  ended(E}access(S,P,0),T). 

(C2) 

endedfE,  access  ( S,P,0),T) 

happens(El,Tl), 

T  <  Tl , 
terminates 

(El,access(S,PtO)). 

(C3) 

ended(E,access(S,P,0),T)  «— 

stop(E ,  Tl ), 
current -  time  ( T2 ), 

Tl  <T2 . 

The  reading  of  this  set  of  rules  is  similar  to  that 
for  CO  :  if  an  event,  E,  happens  at  time,  T,  which 
causes  a  subject,  S,  to  be  given  the  access  right,  P, 
on  a  database  object,  O,  and  the  period  of  time  for 
which  this  right  was  granted  has  not  expired  and  no 
subsequent  event  is  known  to  have  occurred  to  have 
ended  the  right  P  which  S  has  to  access  O  at  time  T 


then  S  holds  the  privilege  P  on  O.  The  variable,  T2,  in 
the  current-time  atom  is  instantiated  with  the  time, 
taken  from  the  “system  clock”,  at  which  the  current- 
time  atom  in  C3  is  selected  in  the  process  of  deciding 
whether  a  privilege  has  expired. 

Notice  that  the  C2  rule  deals  with  the  termination 
of  a  privilege  as  a  consequence  of  the  occurrence  of 
an  event  whereas  C3  deals  with  the  termination  of  a 
privilege  as  a  consequence  of  the  ending  of  a  period 
of  time  for  which  the  privilege  was  granted.  Note  also 
that  the  T  <  Tl  condition  in  the  C2  rule  assumes  that 
properties  hold  only  after  their  initiating  event  hap¬ 
pens.  The  Tl  <  T2  condition  in  C3  is  based  on  the 
assumption  that  event  descriptions  do  not  have  iden¬ 
tical  times  for  the  happens  and  stop  predicates  (any 
attempt  to  include  this  type  of  meaningless  security 
event  description  in  an  authorisation  history  would 
be  rejected  in  the  process  of  validating  event  descrip¬ 
tions). 

To  see  what  is  involved  in  writing  the  domain- 
specific  initiates  and  terminates  rules  for  the  example 
security  model  based  on  A,  we  consider  first  the  ini¬ 
tiates  rule,  PI,  required  to  treat  object  creation.  For 
that,  suppose  that  an  event,  E,  happens  in  which  a 
subject,  S,  creates  an  object,  O,  and  takes  the  right, 
P,  on  O.  This  event  has  the  consequence  of  initiating 
(ie.  making  true)  the  fact  that  S  has  the  right  P  on 
O  viz.  : 

(pi) 

initiates  ( E,  access  ( S,P,0))  «— 

act(E,  create)  t 
creator  (E,S), 
object(E,0), 
mode(E,P). 

Similarly,  if  the  creator  of  object  O  grants  subject 
S  the  right  P  on  O  then  the  initiation  of  a  period  of 
time  during  which  S  may  exercise  the  privilege  P  on 
O  may  be  represented  by  the  following  rule  : 

(P2) 

initiates  (E,access(S,P,0))  4— 

act  (E,  grant), 
grantee(EyS), 
object(E,0), 
mode(E,P). 

To  deal  with  the  granting  of  rights  to  groups  of  in¬ 
dividuals  the  body  of  the  rule  P2  needs  to  be  slightly 
modified  to  include  a  condition  for  testing  for  group 
membership  thus  : 
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(P3) 

initiates  (E,  access(S,PyO))  «— 

act(E}  grant group ), 
grantee  (E,W), 
memberof (Sy  W), 
object(E,0)y 
mode(E,P). 

Notice  that  a  set  of  memberof  facts  (eg.  mem - 
berof (bill ,  sales))  may  be  recorded  in  the  database  to 
permit  group  authorisations  to  be  specified  (the  spe¬ 
cial  group,  public ,  may  also  be  used  to  grant  privileges 
globally)  and  subjects  may  be  members  of  several  dif¬ 
ferent  groups  simultaneously  (without,  as  we  will  see 
later,  conflicting  privileges  arising). 

When  combined  with  an  authorisation  history  and 
the  core  axioms  of  the  SEC,  the  initiates  rules  are 
used  to  infer  the  start  of  an  interval  of  time  for  which 
access  rights  are  held  by  subjects  on  database  objects. 

As  previously  intimated,  for  the  situations  in  which 
the  interval  of  time  for  which  an  access  right  holds 
is  ended  by  a  stop  time  in  an  event  description  the 
C3  axiom  is  used.  For  the  cases  where  an  action  is 
performed  which  ends  the  right  a  subject  has  to  access 
an  object,  a  set  of  terminates  rules  is  required.  These 
terminates  rules  are  used  in  conjunction  with  the  core 
axiom  C2  and  enable  an  owner  of  an  object  to  remove 
privileges  from  subjects. 

The  following  pair  of  terminates  rules  may  be  used 
for  dealing  with  revocations  in  our  example  model  : 

(P4) 

terminates(Eyaccess(SyPyO))  <— 

act( E}  revokeright ), 
revokee(E}S)} 
object(EjO)f 
mode(EfP). 

(PS) 

terminates(E,access(SyPyO))  4— 

act( E,  revokegroupright ), 
revokee(E,  W), 
memberof ( 5,  W )f 
object(EyO), 
mode(E}P). 

Finally,  to  deal  with  the  termination  of  rights  when 
an  object  is  destroyed  by  its  creator  we  may  write  : 

(PS) 

terminates  (Ey  access  (*,  *tO))  «— 

act(E ,  destroy )y 
object(E,0). 


In  P6  the  variable  c*’  denotes  any  subject  and  any 
privilege. 

As  we  have  said,  the  set  of  access  rules,  Pi  ( i 
e  {1..6}),  represents  the  particular  security  model 
which  we  have  chosen  to  use  to  demonstrate  our  ap¬ 
proach.  Different  security  models  may  be  represented 
by  choosing  different  security  actions  to  support  and 
then  writing  the  model-specific  axioms  to  represent 
the  consequences  of  performing  these  actions.  Simi¬ 
larly,  any  number  of  auxiliary  rules  may  be  included 
in  a  security  model  to  simplify  the  specification  of  an 
authorisation  history  (for  example,  a  “write  permis¬ 
sion  implies  read  permission”  rule  may  be  used). 

Notice  that,  unlike  the  specifications  in  [3],  the 
rules  defining  the  security  theory  above  do  not  have 
a  time  interval  associated  with  them  to  represent  the 
periods  during  which  they  are  applicable  to  a  par¬ 
ticular  subject  exercising  a  right  to  access  an  ob¬ 
ject.  In  our  approach,  the  intervals  of  time  for  which 
the  rules  are  applicable  to  a  (subject, privilege, object) 
triple  are  implicit  from  the  times  included  in  an  au¬ 
thorisation  history.  This  simplifies  the  specification  of 
time-constrained  privileges  but  without  compromising 
the  scope  a  security  officer  has  for  representing  secu¬ 
rity  theories. 

5  The  Access  Control  Procedure 

Given  an  authorisation  history,  to  decide  whether 
a  subject,  S,  should  be  permitted  to  exercise  the  priv¬ 
ilege,  P,  on  object,  O,  at  the  time  at  which  access  is 
requested,  the  approach  we  adopt  involves  attempt¬ 
ing  to  prove  that  the  access  request  is  a  theorem  of 
the  authorisation  history  together  with  the  axioma- 
tisation  which  defines  a  chosen  security  model  with 
time-constrained  privileges.  The  existence  of  a  proof 
permits  S  to  perform  P  on  O  at  the  time  at  which  the 
access  is  requested  ;  otherwise  the  access  request  is 
denied. 

Henceforth,  we  will  denote,  by  E,  the  set  of  core 
axioms,  Ci  (i  e  {1..3}),  together  with  the  Pj  rules,  (j 
e  {1..6}),  which  define  our  example  security  model. 
Similarly,  we  will  denote  the  authorisation  history 
given  in  Section  3  by  H. 

Since  E  can  be  described  as  a  set  of  function- 
free  stratified  clauses  [1]  it  follows  that  questions  of 
authorisation  may  be  answered  of  this  security  the¬ 
ory  by  using  safe  SLDNF-resolution  [10].  That  is, 
to  decide  whether  a  subject,  S,  can  exercise  priv¬ 
ilege,  P,  on  a  object,  O,  an  SLDNF- derivation  for 
holds(S,PyO))  may  be  attempted  on  the  security  the¬ 
ory  E  U  H  to  decide  whether  to  permit  the  ac¬ 
cess  request  or  not.  In  this  context,  if  E  U  H 
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U  {<—  holds(access(S,P,0))}  has  an  SLDNF-refutation 
then  subject  S  has  the  privilege  P  on  O.  Conversely,  if 
E  U  H  U  {«— holds(access(S,P,0))}  has  a  finitely-failed 
SLDNF-tree  then  S  does  not  have  the  privilege  P  on 
O. 

Notice  that  it  is  impossible  for  inconsistent  access 
rights  to  arise  in  E  for  any  authorisation  history.  For 
inconsistency,  holds(access(S,PfO))  would  need  to  be 
simultaneously  true  and  false  (for  some  substitution 
for  variables).  Since,  however,  there  is  only  one  defini¬ 
tion  of  holds  in  E  and  SLDNF-resolution  is  consistent, 
it  should  be  clear  that  inconsistent  access  rights  do  not 
arise. 

Before  giving  an  example  of  the  use  of  SLDNF- 
resolution  to  decide  questions  of  access,  we  need  to 
mention  an  important  practical  issue.  For  efficiency 
reasons,  ground  instances  of  the  initiates ,  terminates 
and  ended  predicates  may  be  memoised  [11],  by  dy¬ 
namic  assertion  [17],  when  a  holds(access(S,P,0))  re¬ 
quest  is  first  evaluated.  This  approach,  corresponding 
to  the  use  of  “view  materialisation”  in  [3],  increases 
the  size  of  the  security  theory  but  has  the  advantage 
of  permitting  proofs  of  authorisation  to  be  efficiently 
performed  since  ground  assertions  may  be  used,  al¬ 
most  entirely,  in  the  process  of  deciding  questions  of 
access.  The  existence  of  previously  generated  initi¬ 
ates ,  terminates  and  ended  facts  is  assumed  in  the  ex¬ 
ample,  of  the  use  of  the  access  control  method,  which 
follows. 

Example 

From  the  theory,  E,  and  the  authorisation  history,  H, 
the  following  SLDNF-tree  (which  assumes  a  leftmost 
selection  rule  is  in  force  [10]  and,  for  brevity,  omits  the 
computation  for  not  ended  and  the  alternative  compu¬ 
tations  which  follow  from  <-happens(E,  T))  shows  that 
on  25/1/99  (say)  John  does  not  have  a  write  privilege 
over  ol  : 

<“holds (access (John , write , ol) ) 

I 

< -happens (E,T) , 

init iates(E, access (john, write, ol) ) , 
not  ended(E, access (john, write, ol) ,T) 

I 

<-initiates (el, access (john, write, ol) ) , 

not  ended(el, access(john, write, ol) ,2/1/99) 

I 

<-not  ended(el ,access(john, write, ol) ,2/1/99) 
fail 


The  SLDNF-tree  for  E  U  H  U 
{«— holds(access( John, read, ol))}  is  very  similar  to  the 
one  above.  However,  whereas  ended  succeeds  by  C3 
for  the  holds  (access  (john,wTite,ol))  case,  in  the  test 
for  John’s  possession  of  a  read  right  on  ol  the  ended 
subgoal  finitely  fails  since  John’s  read  privilege  over  ol 
has  been  neither  terminated  by  an  event  nor  stopped 
as  a  consequence  of  the  inclusion  of  a  stop  atom  in  an 
event  description.  Thus,  an  SLDNF-refutation  exists 
for  E  U  H  U  {<—  holds(access(John,read,ol))}. 

It  immediately  follows  from  the  above  that  if  John 
were  to  request  write  access  to  ol  on  25/1/99  then 
that  request  will  be  denied  but  a  read  request  would 
be  allowed. 

An  issue  which  is  sometimes  raised  in  the  context  of 
temporal  authorisation  models  relates  to  the  ending  of 
a  period  of  time  for  which  a  privilege  has  been  granted 
during  the  test  to  determine  whether  a  subject’s  ac¬ 
cess  to  a  database  object  is  permitted  or  not.  In  our 
view  this  is  a  matter  of  practical  concern  rather  than 
a  security  model  issue  and  is  not  specific  to  temporal 
authorisation  models  since,  for  instance,  the  revoca¬ 
tion  of  a  privilege  can  take  place  whilst  a  question 
of  access  is  being  decided  in  a  non-temporal  environ¬ 
ment.  The  problem  does  not,  however,  arise  in  our 
approach.  To  see  why  notice  that,  since  we  assume 
that  a  leftmost  selection  rule  is  used  in  the  SLDNF- 
derivations  performed  on  E,  in  the  C3  rule,  the  cur¬ 
rent  time  is  used  immediately  prior  to  the  test  for  the 
expiration  of  a  time-constrained  access  right.  Hence, 
even  if  a  time-constrained  privilege  does  expire  after 
the  access  control  procedure  has  been  invoked,  it  is 
not  until  the  T1  <  T2  condition  is  evaluated  in  C3 
that  the  expiration  of  a  time-constrained  privilege  is 
checked  and  at  this  point  in  the  computation  the  cur¬ 
rent  time  will  have  been  extracted  from  the  system 
clock  immediately  prior  to  the  test  for  T1  <  T2. 

In  implementations  of  our  approach  periodic 
garbage  removal  may  be  performed  on  the  memoised 
assertions  and  on  an  authorisation  history  (to  remove 
redundant  security  event  descriptions).  For  instance, 
if  the  current  time  is  subsequent  to  the  stop  time  in¬ 
cluded  in  a  security  event  then  the  event  description 
may  be  physically  deleted  from  the  authorisation  his¬ 
tory  together  with  any  facts  which  were  initiated  by 
the  event.  For  instance,  the  event  description  for  el 
could  be  removed  from  H  after  5/1/99  since  John 
does  not  have  write  access  on  ol  after  this  point  in 
time.  If  this  deletion  were  performed  then,  in  any 
subsequent  test  of  John’s  permission  to  write  ol,  the 
access  control  procedure  may  establish  more  quickly 
that  John  does  not  have  this  privilege  since  the  early 
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failure  of  the  initiates(E,access(john}write,ol))  con¬ 
dition  will  cause  holds  (access  ( john,  write,  ol))  to  fail 
early  too.  Similarly,  when  an  object  is  destroyed  the 
event  description  which  created  that  object  may  be 
deleted  together  with  any  dynamically  asserted  initi¬ 
ates,  ended  or  terminates  facts  relating  to  the  object. 
Other  optimisations  which  are  possible  include  chang¬ 
ing  the  order  of  the  conditions  appearing  in  the  rules 
of  £  to  exploit  the  subgoal  selection  strategy  used 
in  an  SLDNF- derivation.  For  example,  by  resolving 
an  initiates(E,access(S,P,0))  subgoal  with  an  appro¬ 
priate  memoised  ground  instance  of  the  same  form, 
it  is  possible  to  delay  selecting  the  non-ground  hap- 
pens(E,T)  condition  in  Cl  until  substitutions  for  E 
and  T  have  been  found. 

Another  practical  issue  which  needs  to  be  con¬ 
sidered  relates  to  the  soundness  and  correctness  re¬ 
sults  applicable  to  the  proof  method  used  to  de¬ 
cide  questions  of  access.  As  we  have  seen,  for  our 
security  model  the  authorisation  test  uses  SLDNF- 
resolution.  As  such,  for  £  (together  with  any  au¬ 
thorisation  history),  Clark’s  2-valued  completion  [4] 
is  a  candidate  declarative  semantics  for  our  approach. 
In  fact,  since  £  is  an  allowed  [14]  and  hierarchical 
[4]  normal  clause  theory  and  holds  (access  (S,P,0))  is 
an  allowed  query ,  it  follows,  from  [15],  that,  for  £, 
(safe)  SLDNF-resolution  is  sound  and  complete  with 
respect  to  Clark’s  semantics  for  determining  the  priv¬ 
ileges  subjects  have  on  database  objects. 

In  this  context,  the  soundness  of  SLDNF-resolution 
implies  that  SLDNF-resolution  correctly  identifies 
which  subjects  have  which  access  rights  on  which 
database  objects.  Conversely,  completeness  means 
that  all  the  access  rights  which  are  implied  by  an  au¬ 
thorisation  history  together  with  £  can  be  derived 
using  SLDNF-resolution. 

The  practical  issue  which  arises  from  the  discussion 
on  soundness  and  completeness  is  that  an  implemen¬ 
tor  needs  to  consider  the  technical  results  which  an 
available  theorem  prover  possesses  when  formulating 
a  security  model  using  the  approach  we  advocate. 

6  Extending  £ 

It  should  be  clear  from  the  discussion  above  that 
a  significant  attraction  of  our  approach  is  that  it  per¬ 
mits  any  number  of  security  theories  with  temporal 
authorisations  to  be  expressed  in  a  simple  and  com¬ 
pletely  uniform  way.  For  a  different  security  theory 
to  £,  fill  that  is  required  is  that  a  different  set  of  ac¬ 
tions  to  those  contained  in  A  be  chosen  and  that  the 
initiates  and  terminates  rules  which  define  the  conse¬ 
quences  of  performing  these  actions  be  formulated. 


In  this  section,  we  consider  some  possible  exten¬ 
sions  to  £  to  demonstrate  the  flexibility  afforded  by 
our  approach.  More  specifically,  we  consider  how  neg¬ 
ative  authorisations  may  be  expressed,  how  shared 
privileges  may  be  specified,  how  proactive  authori¬ 
sations  can  be  supported  and  how  rules  for  default 
authorisations,  like  those  in  [3],  may  be  represented. 

To  permit  negative  authorisations  we  view  a  denial 
as  terminating  the  possibility  of  a  subject  accessing  an 
object  O  to  perform  operation  P  on  O.  In  this  case, 
the  required  terminates  rule  ( C7  say)  is  as  follows  : 

terminates  ( Ef  access  ( S,P,0))  «- 

act  (E,  denying), 
subject(E,S), 
object(E,0), 
mode(E,P). 

This  rule  enables  the  owner  of  an  object  O  to  deny 
S  the  privilege  P  on  O  by  including  a  suitable  security 
event  description  in  an  authorisation  history.  For  ex¬ 
ample,  to  represent  that  (as  of  1/1/99)  Sam  is  to  be 
denied  write  access  to  ol,  the  following  event  descrip¬ 
tion  could  be  included  in  an  authorisation  history  by 
the  creator  of  ol  : 

happens  ( e6,l/l/ 99), 
act( e  6,  de  nying ), 
subject  ( e6,sam), 
object(e6,ol), 
mode  (e6, write). 

By  inspection  of  our  representation  of  the  core 
axioms  of  the  SEC,  it  will  be  clear  that  if  S  is 
denied  the  privilege,  P,  on  O  via  an  event  de¬ 
scription,  A,  in  an  authorisation  history,  II,  and 
holds (access(S,P,0))  is  not  a  theorem  of  a  security 
theory,  T  which  includes  the  C7  rule  and  the  core 
axioms  of  £  then  holds  (access  (S,P,0))  is  not  prov¬ 
able  by  SLDNF-resolution  from  T  U  II  whilst  A 
is  part  of  II.  This  follows  since,  by  C7}  termi- 
nates(E,access(S,P,0))  is  a  theorem  of  T  U  II  where 
E  is  substituted  with  the  event  identifier  for  A.  Sim¬ 
ilarly,  if  holds(access(S,P,0))  is  a  theorem  of  T  at 
time  T1  and  S  is  subsequently  denied  the  privilege, 
P,  on  O  at  time  T2,  as  a  result  of  A  being  in¬ 
cluded  in  an  authorisation  history  (say),  then, 
from  Cl ,  holds  (access  (S,P,0))  is  not  provable  (us¬ 
ing  SLDNF-resolution)  from  ru$,  after  T2,  since 
ended(E,  access (S,P,0),T)  is  a  theorem  of  T  U  ^  us¬ 
ing  C2  together  with  C7. 

It  follows  that  a  denials  take  precedence  over  per¬ 
missions  meta-rule  is  effectively  enforced  by  our  par- 
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ticular  formulation  of  the  core  axioms  of  the  SEC. 
More  specifically,  this  representation  enforces  a  ter¬ 
minates  takes  precedence  over  initiates  conflict  reso¬ 
lution  strategy. 

By  specifying  authorisation  histories  which  include 
denials  of  access,  it  is  possible  to  express  excepted  au¬ 
thorisations  in  our  approach.  For  instance,  it  will  be 
clear  from  the  above  that  to  specify  authorisations  like 
“all  members  of  marketing  can  read  object  o2  except 
Sam”,  what  is  required  is  that  a  pair  of  security  event 
descriptions  be  included  in  an  authorisation  history  ; 
one  which  grants  read  access  to  marketing  whilst  the 
other  records  that  Sam’s  access  to  o2  is  denied. 

To  permit  negative  authorisations  to  be  specified 
as  holding  for  a  restricted  interval  of  time  then  a  not 
denied(access(S,P,0))  condition  may  be  added  to  the 
Cl  axiom  whilst  the  following  rule  is  added  to  the  core 
axioms  : 

denied(access(S,PfO))  <— 

happens  (E}  T1 ), 

act  (E,  denying), 

subject(E,S), 

object(E,0), 

mode(E,P), 

stop(E,T2), 

currenttime(  T3), 

T3  <  T2,  T1  <  T3 . 

That  is,  in  addition  to  access  being  prohibited  as  a 
result  of  the  occurrence  of  an  event  which  terminates  a 
privilege  or  the  expiration  of  a  time  interval  for  which 
a  right  was  granted,  a  subject  S  may  also  be  prevented 
from  exercising  the  privilege  P  on  O  if  S  has  been 
denied  access  to  O  at  time  T1  and  the  period  of  time 
for  which  the  denial  applies  has  not  expired. 

Proactive  initiation  of  authorisations  is  also  possi¬ 
ble  in  our  approach.  To  achieve  that,  an  event  de¬ 
scription  may  be  included  in  an  authorisation  history 
with  an  instance  of  a  happens  (E,T1)  assertion  such 
that  if  T  is  the  current  time  then  T  <  Tl.  As  such, 
it  is  possible  to  specify  on  1/6/99  that  Sal  will  be 
authorised  to  read  ol  from  1/10/99  (say). 

To  specify  that  privileges  may  be  shared  for  a  spec¬ 
ified  interval  of  time,  the  following  rule  may  be  used  : 

initiates  (E,  access  (S,  P}0))  «— 

act(E,  sharing), 
subject(EfSl)) 
sharer  (E,S), 
object(E,0), 
mode(E,P), 

holds  ( access  ( SI,  P,0)). 


This  rule  expresses  that  the  subject  S  may  exercise  the 
privilege  P  on  object  O  for  the  period  of  time  during 
which  subject  SI  has  the  privilege  P  on  O.  The  shar¬ 
ing  rule  may  be  used  with  an  event  description  like 
the  following  which  records  that,  as  of  3/3/99,  Steve 
has  read  access  on  ol  if  and  as  long  as  John  has  this 
privilege  : 

happens  ( e  7, 3/3/99 ), 
act(el,  sharing ), 
subject  ( e  7 John), 
sharer  ( e  7,  steve ), 
object(e7,ol), 
mode  (e7, read). 

In  the  authorisation  model  presented  in  [3],  some 
authorisations  may  be  derived  as  a  consequence  of  the 
absence  of  another  authorisation.  That  is,  authorisa¬ 
tions  “by  default”  are  possible.  For  example,  in  the 
language  in  [3]  it  is  possible  to  use  a  whenevemot  oper¬ 
ator  to  express  that  subject  SI  is  permitted  to  exercise 
privilege  P  on  O  at  all  time  points  at  which  S2  does 
not  hold  the  privilege  P  on  O.  This  type  of  specifica¬ 
tion  is  straightforwardly  expressible  in  our  approach 
using  the  following  axiom  ( C8  say): 

initiates  (E,  access  ( S1,P,  O))  <— 

act( E,  defaultpermit ), 

permitted(E,Sl ), 

excluded(E,S2), 

object(E,0), 

mode(E,P), 

not  holds 

( access  ( S2,P,  O)). 

Conversely,  the  next  rule  enables  the  specifier  of  a 
security  model  to  express  that  at  all  points  in  time 
at  which  subject  SI  holds  a  privilege  P  on  object  O, 
subject  S2  is  prevented  from  exercising  the  P  privilege 
over  O  : 

terminates  (E,  access  ( S2,P,0))  <— 

act(E ,  exclusion ), 
permitted(E,Sl), 
excluded(E,S2), 
object(E,  O), 
mode(E,P), 
holds(access(Sl,P,  O)). 

The  key  point  which  arises  from  this  discussion  is 
that  our  approach  provides  a  security  administrator 
with  a  great  deal  of  flexibility  when  it  comes  to  spec- 
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ifying  a  security  theory  with  time-constrained  access 
rights.  In  principle,  an  implementor  can  choose  to 
support  any  set  of  security  actions  and  any  set  of  priv¬ 
ileges  ;  all  that  is  required  is  that  appropriate  initiates 
and  terminates  rules  be  written  to  define  the  conse¬ 
quences  of  performing  the  selected  security  actions  on 
a  database.  In  contrast,  pre-specifying  a  set  of  secu¬ 
rity  operators  to  be  supported  precludes  the  formu¬ 
lation  of  security  models  which  do  not  include  these 
operators  and,  hence,  limits  the  scope  a  security  ad¬ 
ministrator  has  for  protecting  the  data  in  a  database. 

The  only  constraints  on  a  security  administrator 
who  uses  our  approach  are  those  which  apply  to  the 
methods  used  to  decide  whether  a  subject  S  has  priv¬ 
ilege  P  over  O  ;  whether,  for  instance,  the  methods 
available  for  deciding  questions  of  access  are  sound 
and  complete  (and  with  respect  to  what  semantics). 

7  Summary  and  Conclusions 

By  using  the  simplified  event  calculus  it  is  possi¬ 
ble  to  represent  a  range  of  security  models  for  discre¬ 
tionary  access  control  where  privileges  over  database 
objects  may  be  granted  to  subjects  for  limited  peri¬ 
ods  of  time.  These  security  models  may  be  verified 
to  ensure  that  they  satisfy  organisational  and  tech¬ 
nical  acceptability  criteria  and  may  be  formulated  in 
subsets  of  clausal  form  logic  for  which  efficient,  sound 
and  complete  theorem  provers  are  known  to  exist. 

The  “high-level”  nature  of  the  language  on  which 
the  event  calculus  is  based  and  the  fact  that  users  pro¬ 
vide  security  information  by  writing  ground  atomic 
assertions  makes  the  suggested  approach  especially 
easy  to  use.  Moreover,  a  simple  front-end  may  be 
developed  to  further  ease  the  burden  of  expressing  se¬ 
curity  information. 

Security  models  which  are  directly  based  on  the 
theoretical  framework  outlined  above  have  thus  far 
been  implemented  (in  PROLOG)  and  have  been  suc¬ 
cessfully  employed  to  manage  access  to  relational 
databases.  However,  since  no  assumptions  have  been 
made  about  the  underlying  data  model,  the  approach 
may  also  be  used  with  other  types  of  database. 

In  future  work  we  will  show  how  the  SEC  may  be 
used  to  formulate  a  RBAC  security  model  with  time- 
constrained  privileges  and  how  our  current  work  on 
security  in  deductive  databases  [2]  can  be  extended 
to  include  temporal  authorisations. 
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Abstract 

We  present  a  powerful  authorization  mechanism 
which  supports:  (1)  positive  and  negative  temporal  au¬ 
thorizations;  (2)  user-defined  temporal  rules,  by  which 
authorizations  can  be  derived;  (3)  the  hierarchical  or¬ 
ganization  of  subjects  and  objects,  with  an  associated 
mechanism  for  authorization  inheritance.  The  result¬ 
ing  model  is  very  flexible  in  terms  of  the  protection 
requirements  it  can  represent.  Such  flexibility  requires 
a  non  trivial  underlying  formal  model.  In  particular, 
when  inheritance  and  derivation  rules  are  used  simul¬ 
taneously,  there  is  need  for  conditions  ensuring  that 
the  authorization  base  is  free  from  ambiguities.  For 
this  purpose,  we  introduce  a  notion  of  safeness,  and 
prove  that  it  guarantees  the  absence  of  ambiguities  and 
inconsistencies  in  the  specification.  Moreover,  we  de¬ 
fine  an  efficient  algorithm  for  computing  authoriza¬ 
tions  from  safe  specifications. 

1  Introduction 

In  many  application  domains,  the  need  of  restrict¬ 
ing  access  permissions  to  specific  time  intervals  or  pe¬ 
riods  arises  naturally.  Authorizations  often  need  to  be 
tailored  to  the  pattern  of  users’  activities;  as  an  ex¬ 
ample,  consider  part-time  staff  that  should  be  autho¬ 
rized  for  accesses  only  on  working  days  between  9  a.m. 
and  1  p.m.  Temporal  authorizations  are  also  crucial 
for  optimizing  resource  usage.  For  instance,  execution 
of  resource-expensive  programs  might  be  restricted  to 
specific  time  periods. 

Another  crucial  requirement  is  the  possibility  of  ex¬ 
pressing  the  relationships  that  usually  exist  among  au¬ 
thorization  subjects  and  objects.  In  most  application 
domains,  subjects  and  objects  are  hierarchically  orga¬ 
nized.  The  semantics  of  these  hierarchies  depends  on 
the  considered  domain.  For  instance,  the  object  hier- 
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archy  usually  defines  the  composition  of  an  object  in 
terms  of  other  objects  (e.g.,  a  directory  immediately 
precedes  in  the  hierarchy  the  files  it  contains),  whereas 
the  subject  hierarchy  usually  reflects  the  relative  po¬ 
sition  of  subjects  within  the  organization. 

In  this  paper,  we  present  an  authorization  model 
that  provides  integrated  support  for  all  the  aforemen¬ 
tioned  features.  In  the  model,  temporal  authorizations 
can  be  specified:  positive  authorizations,  for  grant¬ 
ing  a  privilege;  negative  authorizations,  for  explicitly 
denying  a  privilege.  A  temporal  authorization  is  an 
authorization  that  holds  for  specific  periods  of  time. 
Subjects  and  objects  are  organized  into  hierarchies, 
supporting  a  more  adequate  representation  of  their 
semantics.  Authorizations  automatically  propagate 
along  these  hierarchies  in  that  a  subject  may  inherit 
authorizations  specified  for  more  general  subjects  and 
objects,  unless  different  specific  authorizations  are  ex¬ 
plicitly  provided.  Through  inheritance,  many  protec¬ 
tion  requirements  can  be  expressed  concisely.  For  in¬ 
stance,  a  user  may  authorize  all  the  employees  to  ac¬ 
cess  the  files  of  a  given  directory  with  only  one  autho¬ 
rization,  having  as  subject  the  class  “employee”  and  as 
object  the  directory.  Such  an  authorization  automati¬ 
cally  propagates  to  all  the  employees  and  all  the  files  in 
the  directory.  Furthermore,  owners  can  always  specify 
positive  and  negative  exceptions  to  such  general  au¬ 
thorizations,  by  issuing  authorizations  at  the  lowest 
levels  in  the  hierarchies.  Thus,  the  resulting  model 
provides  a  high  degree  of  flexibility  coupled  with  the 
possibility  of  enforcing  stricter  controls  on  crucial  data 
items. 

Our  model  supports  also  temporal  derivation  rules, 
by  which  many  protection  requirements  can  be  con¬ 
cisely  and  clearly  specified.  For  example,  it  is  possible 
to  state  that  two  users,  working  on  the  same  project, 
must  receive  the  same  authorizations  on  certain  types 
of  objects,  or  that  a  user  can  access  an  object  in  cer- 
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tain  periods,  provided  that  nobody  else  is  allowed  to 
access  the  same  object  in  the  same  periods* 

The  work  reported  in  this  paper  is  based  on  the 
model  presented  in  [1],  that  supports  both  temporal 
authorizations  and  derivation  rules.  The  current  pa¬ 
per  extends  [1]  with  the  possibility  of  hierarchically  or¬ 
ganizing  authorization  subjects  and  objects,  and  with 
the  related  inheritance  mechanism.  This  extension  is 
particularly  important  when  dealing  with  the  inter¬ 
operability  of  heterogeneous,  distributed  systems.  In 
this  framework,  different  local  security  policies  have 
to  be  represented  and  integrated  at  a  global  level,  to 
guarantee  interoperability  and  to  detect  possible  in¬ 
consistencies  and  security  breaches  [8].  Such  global 
representation  and  integration  involves  (among  other 
issues)  establishing  mappings  among  different  object 
types  and  subjects.  Such  mappings,  as  when  dealing 
with  integration  of  heterogeneous  data  models,  require 
the  notion  of  hierarchy  for  both  the  object  types  and 
the  subject  types.  We  have  therefore  extended  our 
previous  model  with  hierarchies  in  view  of  supporting 
temporal  authorizations  in  heterogeneous,  distributed 
systems. 

The  introduction  of  hierarchies  for  authorization 
objects  and  subjects  raises  several  theoretical  and  per¬ 
formance  issues.  When  inheritance  and  authorization 
rules  are  used  simultaneously,  subtle  ambiguities  may 
easily  arise,  even  in  very  simple  specifications. 

Example  1.1  Consider  the  following  rules:  (Ri)  if 
subject  s  has  write  permission  on  object  o,  then  s  has 
also  read  permission  on  o;  (R2)  if  s  does  not  have  read 
permission  on  object  o,  then  s  must  not  have  write  per¬ 
mission  on  o,  either.  Assume  also  that  s'  is  the  head 
of  the  administration  department,  and  that  an  autho¬ 
rization  Ai  stating  that  s'  can  write  all  documents  of 
his/her  department  therefore  exists.  Now  consider  a 
classified  administration  document  o'.  The  security 
administrator  tries  to  protect  this  document  through 
a  general  authorization  A2  stating  that  no  user  can 
read  o'.  Unfortunately,  the  resulting  security  specifi¬ 
cation  is  ambiguous.  In  fact,  there  are  two  mutually 
incompatible  possibilities: 

1.  an  authorization  A* ,  stating  that  s'  can  write  o',  is 
inherited  from  Ai,  because  o'  is  an  instance  of  the 
class  of  documents  of  the  administration  depart¬ 
ment.  By  Ri,  it  follows  that  s'  can  read  o'.  Such 
inferred  authorization  blocks  inheritance  from  A2; 
that  is,  it  is  not  derived  that  s'  cannot  read  o'; 

2.  an  authorization  Aj>,  stating  that  s'  cannot  read 
o',  is  inherited  from  A2,  because  s'  is  an  instance 


of  the  class  of  all  users.  By  R2,  it  follows  that  s' 
cannot  write  o'.  This  blocks  inheritance  from  A*; 
that  is,  A'j  cannot  be  derived,  and  s'  cannot  write 
o'. 

Clearly,  it  would  be  hard  to  detect  such  ambiguities 
in  specifications  of  realistic  size,  without  the  help  of 
some  automated  tool.  This  task  is  further  complicated 
by  the  fact  that  authorizations  can  be  independently 
formulated  by  different  users,  and,  generally,  they  are 
not  aware  of  every  single  authorization  and  rule  in 
the  system.  The  standard  solution  to  this  problem 
(adopted  in  [1])  consists  in  requiring  the  rules  to  sat¬ 
isfy  so-called  stratifiability  conditions.  Unfortunately, 
stratifiability  does  not  solve  the  problem;  in  Example 
1.1  above,  rules  Ri  and  R2  can  be  encoded  in  a  specifi¬ 
cation  which  is  stratified,  according  to  [1].  Technically 
speaking,  the  problem  is  that  inheritance  introduces 
“hidden  rules”  that  make  authorization  bases  always 
equivalent  to  non-stratified  logic  programs  [4].  Such 
programs,  in  general,  may  be  ambiguous  (in  the  above 
sense)  or  inconsistent.  Moreover  no  general,  efficient 
way  of  computing  their  models  is  known  (the  prob¬ 
lem  is  NP-hard).  Thus,  dealing  simultaneously  with 
rules  and  inheritance  requires  the  development  of  new 
techniques. 

For  this  purpose,  in  this  paper,  we  introduce  a  no¬ 
tion  of  safeness ,  and  prove  that  it  guarantees  the  ab¬ 
sence  of  ambiguities  and  inconsistencies  in  the  specifi¬ 
cation.  Moreover,  we  define  an  efficient  algorithm  for 
computing  authorizations  from  safe  specifications,  by 
dynamically  refining  a  sort  of  stratification  during  the 
computation. 

The  introduction  of  temporal  features  in  access  con¬ 
trol  on  one  side,  and  the  use  of  logical  formalisms  for 
specifying  authorizations,  on  the  other  side,  have  been 
addressed  by  other  research  efforts.  In  particular,  the 
Kerberos  [9]  system  provides  a  notion  of  ticket ,  with 
an  associated  validity  time.  The  purpose  of  temporal 
tickets  is  very  different  from  our  access  control  model. 
The  former  record  only  the  fact  that  a  client  has  been 
authenticated  by  the  authentication  server;  they  can¬ 
not  be  used  to  grant  access  to  specific  documents  or 
resources  managed  by  the  server. 

From  the  side  of  logical  formalisms  for  security 
specifications,  Woo  and  Lam  in  [11]  propose  a  very 
general  formalism  for  expressing  authorization  rules. 
Their  language  does  not  support  temporal  constraints 
explicitly,  but  it  has  almost  the  same  expressive  power 
as  first  order  logic;  this  makes  it  possible  to  model 
temporal  constraints.  The  main  drawback  is  that  the 
trade-off  between  expressiveness  and  efficiency  seems 
to  be  strongly  unbalanced  in  their  approach.  Jajodia 
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et  al.  in  [6]  propose  a  logic  language  for  expressing  au¬ 
thorization  rules.  Their  language  can  express  most  of 
the  policies  definable  through  the  access  control  mech¬ 
anisms  proposed  so  far  in  the  literature;  however,  tem¬ 
poral  authorizations  cannot  be  expressed.  The  devel¬ 
opment  of  flexible  authorization  models  has  been  ad¬ 
dressed  in  other  papers  [2,  10].  However  none  of  these 
proposals  support  a  complete  set  of  features  as  our 
model,  nor  they  provide  a  formal  foundation  to  their 
models. 

The  remainder  of  this  paper  is  organized  as  fol¬ 
lows.  Section  2  introduces  the  formalism  we  use  to 
represent  periodic  time.  Section  3  illustrates  the  ba¬ 
sic  components  of  the  authorization  model.  Section  4 
gives  their  formal  semantic.  Section  5  introduces  the 
notion  of  safe  authorization  base  and  gives  a  mecha¬ 
nism  to  check  whether  an  authorization  base  satisfies 
this  condition.  Section  6  provides  an  algorithm  to  ef¬ 
ficiently  compute  the  set  of  authorizations  derivable 
from  a  safe  authorization  base.  Section  7  concludes 
the  paper  and  outlines  future  work.  Formal  proofs  are 
reported  in  Appendix  A. 

2  Periodic  Expressions 

A  symbolic  (user  friendly)  formalism  to  represent 
periodic  time  is  provided.  The  formalism  consists  of  a 
pair  ( [begin ,  end] ,  P)  where  P  is  a  periodic  expres¬ 
sion  denoting  an  infinite  set  of  time  intervals,  and 
[begin, end]  denotes  the  lower  and  upper  bounds 
that  are  imposed  on  time  intervals  in  P. 

The  formalism  for  periodic  expressions  is  essentially 
the  one  proposed  in  [7],  based  on  the  notion  of  calen¬ 
dars.  A  calendar  is  defined  as  a  countable  set  of  con¬ 
tiguous  intervals,1  numbered  by  integers  called  index 
of  the  intervals. 

A  subcalendar  relationship  can  be  established  be¬ 
tween  calendars.  Given  two  calendars  Ci  and  C2,  we 
say  that  Ci  is  a  subcalendar  of  C2,  (written  C*  C 
C2),  if  each  interval  of  C2  is  exactly  covered  by  a  fi¬ 
nite  number  of  intervals  of  Ci.  New  calendars  can 
be  dynamically  constructed  from  the  existing  ones,  by 
means  of  a  function  generate ()  (cf.  [1]  for  a  formal 
definition),  a  reference  time  instant ,  and  a  basic  cal¬ 
endar  (the  tick  of  the  system),  denoted  by  _L.  In  the 
following,  we  postulate  the  existence  of  a  set  of  calen¬ 
dars  containing  at  least  Hours ,  Days ,  Weeks ,  Months , 
and  Years ,  where  Hours  is  the  calendar  with  finest 
granularity. 

Calendars  can  be  combined  to  represent  more  gen¬ 
eral  sets  of  periodic  intervals,  not  necessarily  contigu¬ 
ous,  like,  for  instance,  the  set  of  Mondays  or  the  set  of 

xTwo  intervals  are  contiguous  if  they  can  be  collapsed  into 
a  single  one  (e.g.,  [1,2]  and  [3,4]). 


The  third  hour  of  the  first  day  of  each  month .  Com¬ 
plex  sets  of  periodic  intervals,  like  the  ones  above,  are 
represented  by  means  of  periodic  expressions ,  formally 
defined  as  follows. 

Definition  2.1  [1]  Given  calendars  C&,  C\ , . . . ,  Cn,  a 
periodic  expression  is  defined  as  P  =  Oi.Ci  > 

r.Cdi  where  0\  =  all ,  Oi  G  2^  U  {all}  and  Ci  C  C{- 1 
for  i  —  2, . . . ,  n,  Cd  C  C„,  and  r  G  IN. 

The  left-hand  side  of  >  identifies  the  set  of  start¬ 
ing  points  of  the  intervals,  whereas  the  right-hand 
side  specifies  the  duration.  For  example,  all.Y ears  + 
{3, 7}. Months  >  2. Months  represents  the  set  of  in¬ 
tervals  starting  at  the  same  instant  as  the  third  and 
seventh  month  of  every  year,  and  having  a  duration 
of  2  months.  In  practice,  Oi  is  omitted  when  its  value 
is  all ,  whereas  it  is  represented  by  its  unique  element 
when  it  is  a  singleton.  r.Cd  is  omitted  when  it  is  equal 
to  l.Cn. 

The  infinite  set  of  time  intervals  corresponding  to 
a  periodic  expression  P  is  denoted  by  II(P).  Function 
n()  is  formally  defined  as  follows. 

Definition  2.2  [1]  Let  P  =  £”-1  Oi.Ci  >  r.Cd  be  a 
periodic  expression,  then  n(P)  is  a  set  of  time  intervals 
whose  common  duration  is  r  •  Cd,  and  whose  set  S  of 
starting  points  is  computed  as  follows: 

•  if  n=l,  5  contains  all  the  starting  points  of  the 
intervals  of  calendar  Ci ; 

•  if  n  >  1,  and  On  =  {ni, . . . ,  n*},  then  S  contains 

the  starting  points  of  the  n[h, . . .  ,nlh  intervals 
(all  intervals  if  On  =  all)  of  calendar  Cn  included 
in  each  interval  of  Oi.Ci  t>  l.Cn_i). 

For  simplicity,  in  this  paper  the  bounds  begin  and 
end  will  be  denoted  by  date  expressions  of  the  form 
mm/dd/yy  :hh,  with  the  obvious  intended  meaning;  end 
can  also  be  00.  The  set  of  time  instants  denoted  by 
([begin, end],  P)  is  formally  defined  as  follows. 

Definition  2.3  Let  t  be  a  time  instant.  t  G 
SoZ(  [begin,  end],  P)  iff  t  G  II(P)  and  tb  <  t  <  te , 
where  t*,  te  are  the  instants  denoted  by  begin  and 
end,  respectively. 

3  The  Hierarchical  Temporal  Autho¬ 
rization  Model  (HTAM) 

In  this  section  we  illustrate  the  basic  compo¬ 
nents  of  our  hierarchical  temporal  authorization  model 
(HTAM  for  short). 
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subjects  documents 


Figure  1:  An  example  of  subject  and  object  hierarchies 

In  the  following,  5  denotes  the  set  of  subjects,  O  is 
the  set  of  objects,  and  M  is  the  set  of  access  modes. 
Members  of  5  are  the  identifiers  with  which  users  con¬ 
nect  to  the  system.  We  suppose  identifiers  may  refer 
to  single  users  (e.g.,  Ann  or  Bob)  or  roles  (e.g.,  staff 
or  manager).  Subjects  and  objects  are  structured  into 
hierarchies.  Figure  1  shows  an  example  of  subject  and 
object  hierarchies. 

HTAM  supports  positive  and  negative  temporal  au¬ 
thorizations  with  the  following  structure. 

Definition  3.1  [1]  A  temporal  authorization  is  a 
triple  ( [begin, end]  , period, auth),  where  the  pair 
([begin,  end],  period)  represents  a  set  of  time  periods, 
and  auth  is  a  5-tuple  (s,o,m,pn,g) ,  with  s,g  G  S7 
o  €  O ,  m  G  M ,  and  pn  G  {+,  —  }. 

Triple 

([begin, end]  ,P,  (s,o,m,pn,g))  states  that  subject 
s  has  been  authorized  (if  pn  =  c+’)  or  denied  (if  pn  = 

0  for  access  mode  m  on  object  o  by  subject  g  for  each 
instant  in  Sol( [begin, end]  ,P).  For  example,  the  tem¬ 
poral  authorization  Ai  =  ( [1/1/96, oo]  , Mondays, 2 
(Matt ,  oi  ,read ,+ ,Bob)  ) ,  specified  by  Bob,  states  that 
Matt  has  the  authorization  to  read  oi  each  Monday 
starting  from  1/1/96. 

We  assume  that  conflicting  temporal  authorizations 
may  be  simultaneously  specified.  This  is  a  natural 
assumption  both  in  discretionary  frameworks  (where 
different  grantors  may  concurrently  grant  authoriza¬ 
tions  on  the  same  objects)  and  in  federated  databases 
(where  independently  developed  local  security  policies 
need  to  be  merged  to  obtain  secure  interoperation). 
Conflicts  are  dealt  with  according  to  the  denials-take- 
precedence  principle  [5],  unless  one  of  the  conflicting 
authorizations  is  more  specific  than  the  others  with 
respect  to  the  specified  hierarchies.  In  that  case,  less 
specific  authorizations  are  overridden. 

2 Here  and  in  the  following  we  use  intuitive  names  for  periodic 
expressions. 


Example  3.1  Consider  the  hierarchies  illustrated  in 
Figure  1.  Intuitively,  a  temporal  authorization  such 
as  (  [1/1/96, oo ]  ,±,  (staff , admin, read, +, Ann)) 
means  that  all  the  staff  members  can  read,  start¬ 
ing  from  1/1/96,  each  administration  document, 
unless  explicitly  stated  otherwise .  So  for  in¬ 
stance,  in  the  absence  of  further  authorizations, 
( John, d3, read,  +  , Ann)  and  (Bob ,  d7 ,  read ,  +  ,  Ann) 
hold,  starting  from  1/1/96.  On  the  contrary, 
in  the  presence  of  a  temporal  authorization  such 
as  ([l/l/97,oo]  ,_L,  (Bob, d7, read,-, Ann)),  Bob 
would  be  allowed  to  read  document  d7  only  dur¬ 
ing  1996.  More  precisely,  the  authorization 

(Bob, d7, read, +  , Ann)  would  not  be  inherited  after 
the  end  of  1996. 

Similarly,  a  positive  authorization  may  block  the 
inheritance  of  a  negative  authorization.  On  the  other 
hand,  in  case  of  multiple  inheritance,  conflicts  are 
resolved  in  a  conservative  fashion,  according  to  the 
denials-take-precedence  principle  [5]. 

Example  3.2  Consider  the  following  authorizations: 

( [1/1/96, oo]  ,_L,  (staff  ,d6  ,vrite,-,Cleo))  , 

(  [1/1/96, oo]  ,_L,  (Bob,admin,vrite,  +  ,Cleo))}  , 

none  is  more  specific  than  the  other;  in  this  case, 
the  negative  authorization  is  preferred,  and  only 
(Bob, dg, write, -,Cleo)  is  inherited. 

Furthermore,  HTAM  supports  the  specification  of 
user-defined  derivation  rules ,  that  makeS  it  possible 
to  derive  further  authorizations  from  those  explicitly 
given.  Rule  applicability  can  be  constrained  to  specific 
time  periods.  Derivation  rules  are  formally  defined  as 
follows. 

Definition  3.2  [1]  A  derivation  rule  is  a  triple 
( [begin, end]  ,  period,  A  op  F),  where  the  pair 
([begin,  end],  period)  represents  a  set  of  time  peri¬ 
ods,  A  is  an  authorization,  F  is  a  boolean  combination 
of  authorizations,  and  op  is  one  of  the  operators: 
whenever ,  aslongas ,  upon .  The  authorization  A  is 
called  the  head  of  the  rule;  F  is  called  body. 

Definition  3.3  [1]  A  temporal  authorization  base 
(TAB)  is  a  set  of  temporal  authorizations  and  deriva¬ 
tion  rules. 

Roughly  speaking,  rule  ( [begin, end]  ,  P,  A  op 
F)  states  that  for  each  instant  in  Sol(  [begin, end] , 
P),  A  can  be  derived  provided  that  F  is  valid  at  the 
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(Aj)  ([95,5/20/98],  _L , (managers .documents , read,  +  , Sam) ) 

(A2)  ( [10/1/98 ,00] ,  Fridays , (admin-staff , admin, write, +,Sam)) 

(A3)  ([95,98] .Working-days , (CXeo, pi , read,-, Sam)) 

(R-l)  ([96,99],  Working-days,  (tech-staff, admin, read, +  , Sam)  ASLONGAS 
^(admin-staf f , admin, write, +, Sam) ) 

(R2)  ([98, 00],  Mondays  and  Fridays,  (tech-staff .papers .write Sam)  UPON 

-•((managers .papers, read, +, Sam)  V  ( admin- staff .papers .read, +, Sam) ) ) 

(R3)  ([98,99],  Thursday,  (Cleo.di  .read,-, Sam)  WHENEVER  ( John,  d2  ,  read,  +  ,  Sam)  A 
(Ann , d2 , read , + , Sam) ) 


Figure  2:  An  example  of  TAB 


same  instant,  or  in  a  certain  set  of  past  instants  (de¬ 
pending  on  op).  The  grantor  of  A  should  be  the  user 
who  specifies  the  rule. 

The  following  is  an  intuitive  account  of  the  seman¬ 
tics  of  derivation  rules.  It  will  be  assumed  that  all 
authorizations  are  granted  by  the  same  subject;  there¬ 
fore,  the  grantor  will  not  be  considered  in  the  discus¬ 
sion. 

•  ( [begin, end]  ,  P,  A  WHENEVER  F).  We  can 
derive  A  for  each  instant  in  Sol  ([begin,  end],  P) 
where  F  is  valid. 

•  ( [begin, end]  ,P,  A  ASLONGAS  F).  Authoriza¬ 
tion  A  can  be  derived  at  instant  t  in  Sol  ([begin, 
end],P)  if  F  is  valid  for  each  instant  in 
5oi([begin,end],P)  from  the  first  one  up  to  t. 
For  instance,  rule  Ri  in  Figure  2  states  that 
tech-staff  can  read  admin  each  working  day  in 
[1/1/96,12/31/99]  until  the  first  working  day 
in  which  admin-staff  will  be  allowed  to  write 
admin. 

•  (  [begin, end]  ,P,  A  UPON  F).  We  can  derive  A 
for  each  instant  t  in  Sol([ begin,  end],  P)  such  that 
there  exists  an  instant  tr  in  Sol  ([begin,  end],  P) 
t*  <  t  such  that  F  is  valid  at  time  t'.  For  instance, 
rule  R2  in  Figure  2  states  that  tech-staff  can 
write  papers  each  Monday  and  Friday  starting 
from  the  first  in  1998  in  which  both  managers  and 
admin-staff  are  not  authorized  to  read  papers. 

Example  3.3  Consider  the  TAB  in  Figure  2  and  the 
subject  and  object  hierarchies  in  Figure  1.  The  fol¬ 
lowing  authorizations  can  be  derived: 

•  (tech-staff ,  admin,  read, +  ,  Sam)  for  each 

Working  day  in  [1/1/96,10/2/98] ,  from  rule  Ri 


and  authorization  A2.  Note  that  10/2/98  is  the 
first  Friday  after  10/1/98. 

•  (tech-staff , papers, write, +, Sam)  for  each 
Monday  and  Friday  from  5/22/98,  from  rule 
R2  and  authorization  A!.  Note  that  authoriza¬ 
tion  Ai  implies  an  authorization  for  managers  to 
read  papers  for  each  day  in  [1/1/95,5/20/98] . 
5/22/98  is  the  first  Friday  in  [1/1/98, 00]  in 
which  neither  managers  nor  staff  can  read 
papers. 

•  (Cleo,di, read,-, Sam)  for  each  Thursday  from 
1/1/98  to  5/20/98  from  rule  R3  and  authoriza¬ 
tion  Aj.  Note  that  Ai  implies  an  authorization 
for  Ann  and  John  to  read  documents  for  each  day 
from  1/1/95  to  5/20/98  and  this  authorization 
implies  that  Ann  and  John  can  read  document  d2 
for  the  same  days. 

4  Formal  Semantics  of  TABs 

We  start  by  introducing  some  notation.  The  hi¬ 
erarchies  of  subjects  and  objects  are  formalized  by 
two  partially  ordered  sets  (S,  Cs)  and  (O,  Co)  ,  re¬ 
spectively.  For  example,  according  to  the  hierarchies 
illustrated  in  Fig.  1,  we  have  (among  other  relation¬ 
ships)  Ann  Cs  managers ,  John  C5  staff ,  p;  Cq 
documents,  and  p*  £0  admin  (1  <  i  <  k). 

Let  A  be  the  set  of  all  the  tuples  (s,o,m,pn,g). 
Given  an  authorization  A  =  (s,o,m,pn,  g)  we  use  the 
notation  s(A),  o(A),  m(A),  pn(A),  g(A)  to  denote 
the  corresponding  components  of  A.  Let  A+  (resp. 
A“)  denote  the  authorization  obtained  from  A  by  re¬ 
placing  pn(A)  with  ‘+5  (resp.  ‘-’).  For  all  A  €  A,  A 
denotes  the  authorization  complementary  to  A,  that 
is,  A+  —  A~  and  A~  =  A+ .  The  relation  L~~g'  de¬ 
fined  below  is  the  equality  of  authorizations  modulo 
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grantors;  the  set  Conflicts^)  captures  the  set  of  au¬ 
thorizations  conflicting  with  A: 

A  =_£  B  =  s(A)  =  3(B)  A  o(A)  =  o(B) 

A m(A)  ~  m(B)  A  pn(A)  —  pn(B) , 
Conflicts(A)  =  {B\B=-gA}. 

Note  that  B  E  Conflicts^)  A  E  Conflicts(F) , 

and  A  =_5  F  =>  Conflicts(A)  =  Conflicts(F) .  A 
conflicting  pair  consists  of  two  authorizations  A  and 
B  such  that  A  E  Conflicts(F)  (equivalently,  B  E 
Conflicts(A)).  The  subject  and  object  hierarchies  in¬ 
duce  the  following  natural  partial  ordering  C.A  over 

A: 

ACaB  =  3(A)  Qs  8(B)  A  o(A)  C0  o(B) A 

m(A)  —  m(B)  A  pn(A)  =  pn(B)  A  g(A)  =  g(F) . 

As  usual,  A  nA  B  ~  A  CA  BaA  ^  B .  Finally,  define 
the  set: 

Parents^  (A)  = 

{ B  |  A  Ca  B  and  J3C.A  dA  C  CA  B) . 

The  subscripts  of  QA  and  Parents^  will  often  be 
dropped  to  enhance  readability. 

Access  control  is  based  on  the  set  of  time-stamped 
authorizations  that  can  be  derived  from  the  given  TAB 
T.  A  time-stamped  authorization  is  a  pair  ( t ,  A)  where 
t  is  a  non-negative  integer  (a  “tick”  in  the  basic  cal¬ 
endar)  and  A  E  A  (the  intuitive  meaning  is  “A  holds 
at  time  £”). 

Formalizing  derivability  involves  delicate  technical¬ 
ities  due  to  the  presence  of  negation  as  failure .  Rules 
such  as  R—  ([f,£],J_,  A  whenever  -i B~)  axe  triggered 
only  if  (t,F~)  is  not_  derivable ,  and  (£,  A)  should  be 
inherited  only  if  ( t ,  A)  is  not  derivable  (according  to 
the  overriding  mechanism  outlined  in  the  previous  sec¬ 
tion).  Consequently,  derivable  authorizations  cannot 
be  defined  incrementally  through  a  classical  inductive 
definition;  for  example,  the  above  rule  R  may  be  appli¬ 
cable  at  a  certain  stage  of  the  derivation  process,  but 
as  deduction  goes  on,  (t,  B~)  might  become  derivable, 
thereby  invalidating  the  conclusion  of  R.  Informally 
speaking,  in  order  to  decide  whether  R  can  be  ap¬ 
plied  we  should  guess  whether  (t,B~)  will  ever  be 
derived  in  the  future.  Fortunately,  a  similar  form  of 
negation  has  already  been  formalized  in  logic  program¬ 
ming,  through  the  stable  model  semantics  [3];  here  we 
adopt  the  same  idea. 

Intuitively,  the  definition  of  derivable  authoriza¬ 
tions  models  the  following  three  steps:3  (i)  First,  the 

3The  efficient  algorithms  introduced  in  the  next  section  ap¬ 
ply  only  to  safe  TABs  and  do  not  match  the  generate-and-test 
nature  of  the  following  steps. 


set  of  all  derivable  time-stamped  authorizations,  /,  is 
guessed;  (ii)  the  consequences  of  the  given  TAB  T  are 
derived  incrementally,  by  recursively  applying  all  the 
applicable  rules  of  T  and  inheritance;  the  applicabil¬ 
ity  of  inheritance  and  rules  with  negative  literals  in 
the  body — like  R — is  checked  using  I  to  “guess  the 
future”;  (iii)  clearly,  the  initial  guess  is  correct  if  it 
coincides  with  what  can  be  actually  derived  with  the 
given  rules,  i.e.  if  I  equals  the  set  of  authorizations 
derived  in  step  (ii). 

Then,  the  formal  definition  corresponding  to  the 
above  steps  is  just  a  fixpoint  equation  I  —  t  u>, 
where  I  is  the  initial  guess  and  t  is  the  set 
of  authorizations  obtained  in  step  (ii).  In  particular, 
&T  models  a  single  application  (in  parallel)  of  all  the 
applicable  rules  of  T,4  and  the  operator  |  u  iterates 

To  formalize  $ lT  in  a  compact  way,  we  introduce  a 
notion  of  validity  relative  to  the  initial  guess  I.  Recall 
from  the  previous  section  that  conflicting  authoriza¬ 
tions  may  be  simultaneously  derivable  from  T;  in  this 
case  the  denials-take-precedence  principle  is  applied; 
validity  captures  this  idea,  and  it  can  be  extended  to 
arbitrary  boolean  combinations  of  authorizations  in 
negation  normal  form  (NNF).6  Intuitively,  in  the  fol¬ 
lowing,  J  stands  for  the  set  of  authorizations  that  have 
been  derived  at  some  intermediate  step  of  the  deriva¬ 
tion  (I  is  the  initial  guess). 

Definition  4.1  Let  I  and  J  be  sets  of  time-stamped 
authorizations,  t  be  a  time  point,  A  €  A  and  F,  Gi 
be  boolean  combinations  of  authorizations  from  A  in 
NNF.  The  validity  of  F  in  J  at  time  t  w.r.t.  J,  in 
symbols  J,  1 (=*  F ,  is  recursively  defined  as  follows: 

1.  J,  J  j =t  A+  if  (] t ,  A+)  E  J  and 

for  all  B~  E  Conflicts(A+)  ,  (£,  B~)  &  I ; 

2.  if  M")EJ; 

3.  JJ\=t  -.A+if  (t,A+)  g/or 

there  is  F“  E  Conflicts(A+)  s.t.  (tyB~)  E  <7; 

4.  J,I  (=t  -.A”  if  (f,A“)  £  J; 

5.  J,  J  \=t  Gi  A  C?2  if  J,  I J G\  and  J,  J  ^=t  C?2 ; 

6.  JyI\=tGi  VG2if  JJ\=tGi  or  JJt=tG2. 

Now  we  can  define  the  immediate  consequence  op¬ 
erator  that  applies  in  parallel  all  applicable  rules 
and  performs  all  possible  inheritance  steps.  In  the  fol¬ 
lowing,  J  plays  the  role  of  the  set  of  authorizations 

4Note  that  this  operator  depends  on  J,  as  required  by  step 
(ii). 

5 We  recall  the  recursive  definition  of  t:  $  t  0  =  #(0) ;  $  t 

i  +  l  =  $($  T 0  ;  $  t  ^  =  Ui>o  *  t  *  * 

6A  formula  is  in  negation  normal  form  if  negation  is  applied 
only  to  atoms.  This  is  the  form  of  the  bodies  of  TAB  rules. 


232 


which  have  already  been  derived,  and  §!T (J)  is  the 
result  of  one  more  derivation  step. 

Definition  4.2 

*t{J)  =  {  (*,  A)  |  (TJ,  P,  A)  £  T  and  t  £  Sol(TI,  P)  } 

U  {  (i,  A)  |  (TJ,P,  A  whenever  F)  £  T,  t€Sol(TI,P). 

U  {  (t,  A)  |  (TJ,  P,  A  upon  F)  £  T,  t  6  5o/(T7,  P)  and 
3i'  6  Sol(TI,P )  such  that  <  t,  J,  I  P  } 

U  {  (t,  A)  |  (T/,  P,  A  aslongas  F)  €  T,  £  £  Sol(TI ,  P)  and 
for  all  £;  €  Sol(TI,P)  such  that  £7  <  £,  J,  /  |=t»  P} 

U  {  (£,  A)  |  3Ai  6  Parents(A).  J ,  I  (=*  A\ 
and  VA2  £  Conflicts(A).  A2  £  /  , 
and  if  A  —  A+  then  VA3  £  Parents(Conflicts(A)). 

J,/N  ^s}. 

The  first  four  sets  in  the  right-hand  side  formalize 
the  semantics  of  TAB  rules;  the  last  set  defines  the 
semantics  of  inheritance.  The  precedence  of  negative 
authorizations  over  positive  authorizations  is  obtained 
by  inheriting  A+  only  when  no  conflicting  authoriza¬ 
tion  B  £  Conflicts(A+)  can  possibly  be  inherited;  in 
turn,  this  is  verified  by  checking  that  no  parent  A3  of 
B  is  valid. 

As  we  have  already  pointed  out,  by  iterating  the 
above  operator  we  obtain  all  the  facts  derivable  from 
T,  given  the  initial  guess  I . 

Proposition  4.1  The  operator  is  continuous, 
and  hence  i)  &T  f  0  C  |  1  Q  . .  -  C  ^  t  ^  ; 
ii)  the  least  fhpoint  of  is  t  U)  . 

Thus,  the  initial  guess  is  correct  iff  I  coincides  with 
**T  f  u.  So  the  notion  of  C-stable  model  introduced 
below  captures  the  set  of  derivable  authorizations. 

Definition  4.3  A  set  of  time-stamped  authorizations 
I  is  a  Q-stable  model  of  a  TAB  T  iff  I  =  &T  t  a; . 

Suppose  that  T  has  one  C-stable  model  M;  then  an 
authorization  A  should  be  enforced  at  time  t  iff  A  is 
valid  in  M  at  time 

5  Dynamically  Stratified  TABs 

A  TAB  may  have  multiple  C-stable  models,  or  no 
C-stable  models  at  all.  In  this  section,  we  introduce 
conditions  that  guarantee  that  the  TAB  has  exactly 
one  C-stable  model  (and  hence  a  consistent,  non  am¬ 
biguous  semantics). 

A  labeled  dependency  graph  is  a  graph  whose  nodes 
are  authorizations  from  A  and  whose  edges  are  labeled 
with  +,  —  or  v  (accordingly,  the  edges  are  called  pos¬ 
itive,  negative  or  variable). 


Let  DGr(t)  be  the  labeled  dependency  graph  whose 
set  of  nodes  is  A  and  whose  edges  are  all  and  only 
the  triples  ( A,  l,  B)  that  satisfy  some  of  the  following 
conditions: 

(DG1)  For  some  rule  (TI,  P,  B  (  op )  F)  £  T 
such  that  t  £  Sol(TI,P ),  A  occurs  in 
F ;  moreover,  if  A  occurs  in  the  scope  of 
a  negation  sign  (-»),  then  l  =  —  ,  other¬ 
wise  l  =  + ; 

(DG2)  A  £  Conflicts(Af ),  where  A+  oc¬ 
curs  in  the  body  F  of  some  rule 
(TJ,  P,  B  ( op )  F)  £  T  such  that  t  £ 
Sol(TI,P );  moreover,  if  Af  occurs  in 
the  scope  of  a  negation  sign  (-1),  then 
l  =  + ,  otherwise  Z  =  — ; 

(DG3)  A  £  Parents(B)  and  l  =  - ; 

(DG4)  A  £  Conflicts(B)  and  l  =  v . 

TABs  will  be  required  to  satisfy  the  following  safeness 
conditions.  We  shall  prove  that  safeness  guarantees 
the  existence  of  a  unique  stable  model. 

Definition  5.1  A  TAB  T  is  safe  if  for  all  t  >  0:  1) 
no  cycle  in  DG(t)  contains  a  negative  edge;  2)  if  A,  B 
is  a  conflicting  pair,  then  every  path  from  A  to  B  in 
DG(t)  contains  a  variable  edge  (A',v,B')  such  that 
A'  =-g  A  and  B'  =_p  B . 

A  stratification  of  a  set  of  authorizations  A1  C  A 
is  a  mapping  7r  :  A'  ->  { 1, . . . ,  \Af  \  }  .  We  say  that  7r 
is  compatible  with  a  labeled  dependency  graph  DG  if: 
1)  for  all  edges  ( A,  Z,B)  in  DG ,  7 r(A)  <  7r(B) ,  and  2) 
if  Z  =  —  then  7r(A)  <  7r(B) . 

In  the  standard  logic  programming  setting,  the  ex¬ 
istence  of  a  compatible  stratification  is  equivalent  to 
the  “safeness”  of  the  program.  On  the  contrary,  here 
safeness  is  stronger  (the  second  condition  is  not  en¬ 
forced  by  the  existence  of  a  stratification).  Intuitively, 
the  problem  is  that  for  every  conflicting  pair  A,  B ,  the 
inheritability  of  A  depends  on  the  absence  of  B  and 
viceversa.  Fortunately,  this  cyclic  (non-stratifiable) 
dependency  does  not  affect  the  nice  properties  of  strat- 
ifiable  programs  (i.e.,  the  existence  of  a  unique  stable 
model  which  can  be  computed  in  polynomial  time). 

The  model  of  a  TAB  T  which  satisfies  the  safe¬ 
ness  conditions  can  be  constructed  as  follows.  Let 
iTt  :  A  — >  {1,...,|A| }  be  a  stratification  compati¬ 
ble  with  DGr{t)  •  We  call  7r*  a  pre-stratification  of 
A  at  time  t.  Define  Atj  =  {A  |  7r*(A)  =  Z}.  A  re¬ 
fined  stratification  of  At,i  w.r.t.  an  interpretation  J  is 
a  mapping  crtj  :  Atj  {  1, . . . ,  \Atj  \  }  such  that  for 
all  A,  B  £  At,i : 
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1.  if  (A,  +,B)  belongs  to  DGr{t)  then  atj(A)  < 

2 .  if  (A+,v,B)  is  in  DGr(t)  and  3 B'  6 
Parents(Conflicts(A)).  J,  J  |=f  B'  then  (rtyi(A)  < 

3.  if  (A“,t;,i3)  is  in  JX?r(£)  and  /  3-4'  € 

Parents(Conflicts(B)).  J,  J  |=<  A'  then  cr*/(A)  < 

Note  that  at,i  is  a  stratification  compatible  with  a 
modified  version  of  DGr(^) ,  where  the  variable  edges 
over  At, i  have  been  either  eliminated  or  turned  into 
negative  edges.  The  idea  is  that  the  negative  cycles 
involving  conflicting  pairs  can  be  “broken”  dynami¬ 
cally,  on  the  basis  of  the  part  of  model  built  so  far 
(represented  here  by  J).  Indeed,  in  the  full  paper  it 
is  shown  that  for  each  conflicting  pair  A,  B ,  either 
<  <Tt,i(B)  or  <rtj(B)  <  <rt,i(A)  • 

The  model  M  is  constructed  through  three  nested 
iterations,  over  time,  pre-stratification  level  and  re¬ 
fined  stratification  level,  respectively.  In  order  to  sim¬ 
plify  notation,  we  shall  use  r  as  an  abbreviation  of 
an  arbitrary  triple  (£,  Z,i)  of  the  form  (0,0,0)  or  such 
that  t  >  0,  1  <  l  <  \A\  and  1  <  i  <  \Atj\.  With 
a  slight  abuse  of  notation,  the  lexicographic  ordering 
of  such  triples  will  be  denoted  by  <,  and  the  imme¬ 
diate  predecessor  and  successor  of  r  in  this  ordering 
will  be  denoted  by  r  —  1  and  r  +  1,  respectively.  Each 
time-stamped  authorization  (£,A)  will  be  associated 
to  a  layer  £(t,A)  =  where  l  =  irt(A)  and 

i  =  &t,i(A) .  Finally,  define  by  mutual  recursion:  7 

M  =  Ut>(o,o,o)  Mr .  where 

MT  —  0  if  r  =  (0, 0, 0),  otherwise 
MT  =  t  w(Mr— i) ,  where 


T{tM  =  m,t],P,A(op)F)\ 

([tb,te],P,  A(op)F)  €  T, 
t  €  Sol([tblte],P ),  gtm(A)  =  i} 

U  {([**, f],P,  A)  I  (Me],P,  A)  e  T, 
t  e  Sd([tb,te],P ),  (Ttji(A)  =  i} 

and  where  a t,i  is  a  refined  stratification  of  At,i  w.r.t. 
Af(£,U)-i  •  speaking,  is  the  set  of  rules 

and  authorizations  that  can  possibly  be  used  to  derive 
time-stamped  authorizations  whose  layer  is  (t,/,i). 
Note  that  depends  on  x)-i  through  <jt,i  • 

7 Recall  that  t  0(J)  =  J  and  $!T  t  *+l(  J)  =  t 
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First,  it  must  be  shown  that  the  above  construction 
is  well  defined,  by  proving  that  pre-stratifications  7rt 
and  refined  stratifications  at,i  exist. 

Theorem  5.1  If  T  satisfies  the  safeness  conditions 
then  7rt  and  ot,i  exist  for  all  t  >  0  and  for  all  l  (1  < 

1<\A  |). 

Theorem  5.2  M  is  the  unique  C- stable  model  ofT. 

Definition  5.1  above  gives  a  method  to  test  whether 
a  given  TAB  satisfies  the  safeness  conditions.  Such 
test  is  performed  by  checking  a  set  of  conditions,  for 
each  instant  t  >  0.  Obviously,  this  test  is  feasible  in 
practice  only  if  we  can  safely  stop  it  at  some  finite 
instant  t.  The  particular  form  our  rules  allows  us  to 
ensure  the  existence  of  this  finite  constant,  denoted  in 
the  following  as  max-time,  max-time  is  determined 
as  tmax  +  k  ■  P max,  where  tmax  is  the  greater  instant 
corresponding  to  an  end  date  expression  in  TAB,  ?max 
is  the  least  common  multiple  of  all  the  periodicities  of 
the  periodic  expressions  appearing  in  TAB,  and  k  is 
the  maximum  number  of  ASLONGAS  and  UPON  rules  in 
TAB  plus  one.  The  important  property  is  that,  after 
instant  max-time,  the  validity  of  any  authorization  in 
TAB  becomes  periodic.  The  proof  of  the  existence  of 
max-time,  adapted  from  [1],  is  contained  in  Appendix 
A. 

6  Access  Control 

Two  different  strategies  can  be  used  to  enforce  ac¬ 
cess  control:  run-time  derivation  and  materialization. 
Under  the  latter  approach,  the  system  permanently 
maintains  all  the  valid  authorizations  derivable  from 
a  TAB.  Access  control  therefore  becomes  very  efficient; 
as  a  drawback,  the  materialization  has  to  be  properly 
updated  every  time  the  TAB  is  modified. 

Like  in  [1],  we  adopt  the  materialization  approach. 
The  main  reason  behind  this  choice  is  that  in  real 
systems  access  requests  are  generally  considerably 
more  frequent  than  requests  modifying  authorizations 
and/or  rules. 

In  Appendix  A,  a  natural  extension  of  the  results 
in  [1]  to  our  case  is  presented.  In  particular,  it  is 
proved  that  there  exists  an  instant  ti  which  can  be 
used  to  limit  the  computation.  The  model  at  time  ti 
can  be  used  to  check  the  validity  of  any  authorization 
for  each  instant  t  >  0.  Given  a  model  M,  we  call  the 
compact  version  of  M,  denoted  as  Mc,  the  subset  of 
M  satisfying  the  above  condition. 

Figure  3  presents  an  algorithm  to  compute  the  com¬ 
pact  version  of  the  model  of  a  TAB  T  which  satisfies 
the  safeness  condition. 
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Algorithm  5.1 

INPUT:  A  TAB  T  satisfying  the  safeness  condition 

OUTPUT:  The  compact  version  Mc  of  the  model  M  of  T 
METHOD: 

1.  Let  be  the  minimum  instant  corresponding  to  a  begin  date  expression  in  T 

2.  Let  t max  be  the  greater  instant  corresponding  to  an  end  date  expression  in  T 

3.  Let  P max  be  the  Icm  of  all  the  periodicities  of  the  periodic  expressions  in  T 

4.  Let  k  be  the  maximum  number  of  aslongas  and  UPON  rules  in  T  plus  one 

5.  max-time  tmax  +  k  *Pmai,  k  :=  1,  success  :=  false,  Mc  0 

6.  Compute  7rt ,  for  each  t  such  that  tmtn  <  t  <  t max  -b  Pmar 

7.  Repeat 

k  k  +  1,  current-max  :=  tmax  +  k  •  P max 

Compute  7 re,  for  each  t  such  that  current  —max  P m ax  t  ^  current— max 

For  t:~  t min  to  current-max  do 
Let  l*  :=  max{l  |  l  =  7Tt(A)} 

For  i  :=  1  to  l *  do 

Let  Tt,i  ■■=  T(t,  i)  U  INH(MC  ,t,i)\JTAB(Mc) 

Let  Li,...Lh  be  a  stratification  of  Ttfi 
For  j  :=  1  to  h  do 

Let  Tt,ij  :=  {  ([t6)  t],  P,  A{  op  )F)  |  ([4,  t],  P,  A{  op  )F)  €  Tt,i, 

(t,A)  e  Lj}  u  {([t6,t],P,yi)  I  ([i6,t],p,/i)  €  Tt,i,(t,A)  e  L, } 

Repeat 

For  each  x  E  Ttjj  do 

Ifx  =  ([*&,i]>F\  A{  op  )F)  and  V£“  EConflicts(A)  (t,£~)  £  Mc  then 
If  op  =  WHENEVER  and  Mc  \=t  F  then  add  (£,  A)  to  Mc 
If  op  =  ASLONGAS  and  VP  tb  <  t'  <  t  Mc  f=t/  F  then  add  (t,  A)  to  Mc 
l  If  op  =  upon  and  3t'  tb  <  t!  <  t  such  that  Mc  \=t,  F  then  add  (A,  t)  to  Mc 

endif 

If  z  =  {[t,t),P,A)  and  VB~  eConflicts(/l)  £  Mc  then  add  ( t,A )  to  Mc 

Until  Mc  does  not  change 

endfor 

If  Cfc-i  =  Ck  then  success  true 
Until  success  or  current-max  >  max -time 

Figure  3:  An  algorithm  for  computing  the  compact  version  of  the  model  of  a  TAB 


In  Algorithm  5.1,  the  treatment  of  the  temporal 
aspects  is  similar  to  the  one  introduced  in  an  analo¬ 
gous  algorithm  in  [1].  The  treatment  of  the  derivation 
rules  is  based  on  the  model  computation  given  in  Sec¬ 
tion  5.  It  computes  the  difference  between  and 

M(tti+i}o)  (for  increasing  l  and  t )  by  transforming  the 
part  of  the  TAB  relevant  to  time  t  and  level  l  +  1  into 
a  TAB  without  inheritance.  For  this  purpose,  for  all 
sets  of  time-stamped  authorizations  M,  for  all  time 
points  t  and  levels  l  let: 

TAB(M)  =  {([tit],±1A)\(t,A)eM}i 
INH(M,t,l)  =  {  A  whenever  F)  \  7 r*(A)  =  l , 

3Ai  G  Parents(A).M  \=t  Ai , 
if  A  =  A+  then  VA2  6  Parents(Conflicts(A)), 
M£tA2,F=  f\  ->B } , 

Conflicts  (A) 

T(t,l)  =  {([tb,t},P,A(o?)F)\ 


{[tb,te],P,A(  op  )F)  G  T, 

t  e  Sol( [begin,  end],P),  nt  (A)  =  1} 

U{([hAP,A)\([tb,t'lP,A)eT, 

t  G  5o/([begin,  end],P),  7 r*(A)  =  / }  . 

Intuitively,  TAB(M)  transforms  its  argument  (that 
will  be  the  part  of  the  model  already  computed)  into 
an  equivalent  TAB;  INH(M,t,l)  transforms  the  ap¬ 
plicable  inheritance  rules  into  explicit  whenever  rules; 
T(t ,  7)  is  the  restriction  of  T’s  rules  and  authorizations 
to  layer  l  at  time  t .  Finally,  for  all  7  s.t.  t+Z  >  0,  let: 

Tt,i  = 

The  next  theorem  states  that  the  above  transforma¬ 
tion  yields  a  well-behaved  TAB  that  captures  exactly 
level  7  at  time  t. 

Theorem  6.1  For  all  t ,  l  s.t  t  +  l  >  0,  i)  Tt,i  is  a 
stratified  TAB;  ii)  The  stable  model  ofTtj  agrees  on 
validity  with  . 


The  complete  algorithm  works  as  follows.  First,  it 
computes  for  each  instant  t  between  t min  and  cur¬ 
rent-max,  where  t min  is  the  minimum  instant  corre¬ 
sponding  to  a  begin  date  expression  in  TAB  and  cur - 
rent-max  is  initially  set  equal  to  trnax+?rnax  and  incre¬ 
mented  by  ?max  at  each  iteration.  Then,  for  each  level 
l  of  the  stratification  and  for  each  instant  t  between 
t  min  and  current-max ,  the  algorithm  transforms  the 
part  of  the  TAB  relevant  to  time  t  and  level  l  into  a 
TAB  without  inheritance  (using  the  method  sketched 
above).  According  to  Theorem  6.1  the  resulting  TAB 
is  stratified.  Thus,  we  can  apply  the  algorithm  devel¬ 
oped  for  such  TABs  (see  [1])  to  compute  a  stratifica¬ 
tion  for  level  /,  as  well  as  the  authorizations  of  level  l 
derivable  from  the  TAB  at  time  t. 

Then,  the  algorithm  considers  the  computed  time- 
stamped  authorizations  in  two  contiguous  time  inter¬ 
vals  after  tmax  of  length  equal  to  Pmax  and  checks 
whether  these  sets  are  equivalent  (C&_i  =  (7*).  If  so, 
the  behavior  is  already  periodic  and  the  algorithm  ter¬ 
minates.  If  not,  and  if  the  considered  interval  do  not 
exceed  max-time,  it  proceeds  with  another  iteration  of 
the  Repeat-until  cycle,  generating  a  larger  model  us¬ 
ing  the  constant  of  the  previous  iteration  incremented 
by  Pma*. 

In  practice,  we  expect  the  algorithm  to  terminate 
at  the  first  iteration  in  most  cases.  The  following  the¬ 
orem  states  the  termination  and  the  correctness  of  Al¬ 
gorithm  5.1. 

Theorem  6.2  i)  Algorithm  5.1  terminates ,  and  ii) 
an  authorization  A  is  valid  at  time  t  iff  one  of  the  fol¬ 
lowing  conditions  holds.  Let  t  be  the  greatest  instant 
appearing  in  a  time-stamped  authorization  in  Mc ,  and 
let  t*  be  the  minimum  instant  such  that  t  <t*  and  t* 
~  tmai  +  71  *  P rnaxf  ^  £  IN . 

•  t  <  i,  and  (t,k)  e  Mc ; 

•  t>  i,  and  there  exists  an  instant  tf,  t*  —  Pma*  < 
tf  <  t*  such  thatt1  =  t— k-?max  and  (t',k)  €  Mc . 

7  Conclusions 

In  this  paper  we  have  presented  a  powerful  autho¬ 
rization  mechanism  which  provides  support  for  tempo¬ 
ral  authorizations,  user-defined  derivation  rules,  and 
the  hierarchical  organization  of  subjects  and  objects. 

We  have  given  a  solution  to  the  problems  related 
to  the  simultaneous  presence  of  inheritance  and  au¬ 
thorization  rules.  Variable  edges,  safeness  and  the  dy¬ 
namic  stratification  mechanism  have  no  counterpart 
in  the  literature.  Safeness  guarantees  that  the  TAB  is 


consistent  and  unambiguous.  Moreover,  we  have  de¬ 
signed  an  effective  algorithm  for  computing  a  compact 
version  of  the  unique  model  of  safe  TABs. 

Sometimes,  in  the  presence  of  ambiguities,  it  may 
be  possible  to  select  one  stable  model  of  the  TAB,  by 
taking  into  account  additional  information,  such  as  the 
grantors  of  the  conflicting  authorizations,  or  priorities 
defined  over  access  modes.  This  will  be  the  subject  of 
future  work. 
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A  Main  Proofs 

Lemma  A.l  Let  T  be  a  safe  TAB  and  let  M  be  its 
model.  Let  Ci  =  {(£,  A)  |  (£,A)  E  M  and  tmax  + 
(i  l)  P max  ^  t  5;  ^max  H"  f  *  Pmoi}-  Given  C{  and 
Cj ,  we  say  that  Ci  and  Cj  are  shift-equivalent  (written 
Ci  ==  Cj)  if  for  each  pair  (t,A)  in  C{  a  corresponding 
one  (with  the  same  authorization)  can  be  found  in  Cj 
by  “ shifting ”  the  temporal  instant  t  by  the  value  ( j  — 
i)  •  P max?  and  vice  versa.  Thus,  here  exists  an  integer 
k  such  that  Ck  =  C^  for  each  k  >  k.  The  integer  k  is 
limited  by  one  plus  the  number  of  ASLONGAS  and  UPON 
rules  in  T  having  an  unbound  associated  interval 

Proof.  To  prove  the  thesis  it  is  sufficient  to  con¬ 
sider  the  derivation  of  pair  (£,A)  at  instants  greater 
than  tmax.  Since  any  derivation  of  a  pair  (i,A)  with 
t  >  tmax  is  possible  only  through  a  rule  or  an  autho¬ 
rization  with  an  unbound  associated  interval  (that  is, 
an  interval  of  the  form  [begin, oo]),  we  only  consider 
authorizations  and  rules  in  T  with  an  unbound  asso¬ 
ciated  interval.  The  proof  is  articulated  in  three  main 
steps: 

1.  Ci  ^  Ci+i  implies  that  there  exists  a  rule  in  T 
and  two  instants  t  and  if  in  the  z-th  period  with 
t  <tf,  such  that  (i)  either  the  rule  operator  is  AS¬ 
LONGAS  and  the  rule  fires  at  t  and  not  at  t or  (ii) 
the  operator  is  UPON  and  the  rule  does  not  fire  at 
time  £,  while  it  fires  at  time  t Intuitively,  this 
statement  says  that,  in  the  z-th  period,  either  an 
ASLONGAS  rule  “expires”  or  an  UPON  rule  “trig¬ 
gers”.  To  prove  this  statement  we  first  note  that  if 
only  explicit  authorizations  and  WHENEVER  rules 
are  present  in  TAB,  then  Ci  =  C*+ 1- 

Hence,  Ci  ^  Ci+  \  implies  the  existence  of  an  AS¬ 
LONGAS  rule  Ra  or  of  an  UPON  rule  Ru ,  and  of  an 
authorization  A  such  that  the  rule  derive  (£,A)  and 
not  (£+Pmax,  A),  or  viceversa.  Consider  first  the 
ASLONGAS  case  with  Ra  =  ([begin,  oo],  P,  A 


ASLONGAS  F),  and  let  t(  with  t<t'<  £+ Pma*  be 
the  first  instant  in  Sol{  [begin,  oo]  ,P)  for  which 
rule  Ra  cannot  derive  (£',A).  Thus,  there  exists 
a  conjunct  L  in  F  such  that  either  i)  L  ~  a'  and 
(£', A')  £  M  or  ii)  L  =  ™>A'  and  (£',A;)  E  M.  t ' 
could  be  in  the  z-th  period,  in  which  case  the 
above  statement  would  be  proved,  or  in  the  (z-f  1)- 
th  period.  In  this  last  case,  since  it  is  the  first  in¬ 
stant,  we  have  that  either  i)  L  =  A'  (£'  -  Pmaa:>A') 
6  M  and  (£\A')  £  M  or  ii)  L  =  -iA'  (£'-Pmax,A') 
£  M  and  (£', A')  E  M.  Then,  we  can  recursively 
apply  the  same  reasoning  for  L  as  for  (£,  A).  It 
is  easily  seen  that,  eventually,  either  we  find  an 
ASLONGAS  rule  that  “expires”  in  the  z*-th  period, 
or  we  find  a  conjunct  derived  by  an  UPON  rule. 

A  similar  reasoning  can  be  done  for  the  UPON 
rule  case,  i.e.,  we  consider  the  first  instant  t '  in 
the  z-th  period  for  which  the  rule  Ru  can  derive 
(£',  A).  Eventually,  either  we  find  an  UPON  rule 
that  “triggers”  in  the  z-th  period,  or  we  find  a 
conjunct  derived  by  an  ASLONGAS  rule.  Hence, 
the  statement  in  item  1  holds. 

2.  Given  two  pairs  (Ci,Ci+i)  and  (Ck,Ck+ 1)  such 
that  Ci  ^  Ci+i  and  Ck  ^  Ck+ 1,  the  rules  ex¬ 
piring  (triggering,  resp.)  in  the  z-th  period  and 
in  the  k-th  period,  as  stated  above,  are  different 
aslongas  (upon  resp.)  derivation  rules  in  TAB. 
Indeed,  consider  the  case  of  aslongas.  We  as¬ 
sume,  without  loss  of  generality,  that  i  <  k.  Let 
Ra  —  ([begin,  oo],  P,  A  ASLONGAS  F)  be  one 
of  the  ASLONGAS  rules  expiring  in  the  z-th  pe¬ 
riod,  and  let  tl  E  Sol{ [begin, oo],P)  be  the  first 
instant  in  the  z-th  period,  such  that  Ra  cannot 
be  fired  to  derive  (£', A).  Hence,  at  least  one  of 
the  conjunct  L  in  F  is  such  that  either  i)  L  =  A' 
and  (£', A')  0  M  or  ii)  L  =  — iA7  and  (£', A')  E  M. 
It  is  easily  seen  from  the  semantics  of  ASLONGAS 
that  this  rule  cannot  be  used  anymore  to  derive 
authorization  A,  that  is,  there  cannot  exist  an  in¬ 
stant  t”  >  t '  such  that  (£', A)  E  M  and  (t*, A)  is 
derived  from  Ra.  Suppose,  by  contradiction,  that 
the  rule  Ra  can  be  used  to  derive  (£", A),  with  t " 
in  the  (A;  +  l)-th  period.  Let  us  consider  the  con¬ 
junct  L  in  F  considered  above.  Suppose  that  i 
holds  (the  proof  for  ii)  is  analogous)  that  is,  L 
=  A7.  Thus,  (£*, A7)  E  M  Wt*  E  Sol ( [begin, oo],P), 
t*  <  t ".  Thus,  (£', A')  E  M,  which  is  clearly  a  con¬ 
tradiction.  The  arguments  for  UPON  are  similar 
and  we  omit  them.  This  proof  immediately  leads 
to  the  result  that  the  maximum  number  of  ‘dif¬ 
ferent”  CiS  is  limited  by  one  plus  the  maximum 
number  of  ASLONGAS  and  upon  rules  in  TAB.  In- 


deed,  each  rule  can  be  responsible  for  (at  most) 
one  relation  C\  ^  Ci+ x. 

3.  Ci  =  Ci+ 1  implies  Q  =  Cj  for  each  j  >  i.  To 
prove  this  statement  it  is  sufficient  to  show  that 
Ci  =  Ci+ 1  implies  Ci+\  =  C*+ 2-  Suppose  by 
contradiction  that  Cj  =  Ci+x  but  Ci+ 1  ^  Ci+2* 
By  item  1  above,  this  means  that  there  exists  a 
rule  in  TAB  and  two  instants  t  and  t!  in  the  (z+1)- 
th  period  with  t  <t! ,  such  that  (i)  either  the  rule 
operator  is  aslongas  and  the  rule  fires  at  t  while 
it  does  not  fire  at  or  (ii)  the  operator  is  UPON 
and  the  rule  does  not  fire  at  £,  while  it  fires  at 
tr .  Consider  case  (i),  and  let  (£,A)  be  the  pair 
derived  by  the  rule.  Hence,  (£,A)  E  Ci+ 1  and 
(£',  A)  g  Ci+ 1-  However,  since  Ci  =  Ci+x,  then 
(£'  -  Pmoz,  A)  0  Ci.  This  means  that  rule  expired 
in  the  z-th  period  and  this  contradicts  the  fact 
that  the  same  rule  can  derive  ( t ,  A)  in  the  (z  +  1)- 
th  period.  Consider  case  (ii),  and  let  (t',A)  be 
the  pair  derived  by  the  rule.  Hence,  (£',  A)  E  Ci+ 1 
and  (t,  A)  £  C{+ 1.  However,  since  Ci  =  Cj+i, 
then  (*'  -  Pmaij  A)  E  C*.  This  means  that  rule 
triggered  in  the  z-th  period  and  this  contradicts 
the  fact  that  the  same  rule  cannot  derive  (£,  A)  in 
the  (t  +  l)-th  period. 

From  items  2  and  3,  we  can  easily  conclude  the 
thesis.  □ 

Proposition  A.l  For  each  conflicting  pair  A,B ,  ei¬ 
ther  atli(A )  <  0t,i(B)  or  crtyi{B)  <  crtj(A) . 

Proof  For  all  conflicting  pairs  A ,  B ,  both  ( A ,  v ,  5) 
and  (B,v,  A)  belong  to  DG[t).  First  suppose  that  A 
is  positive;  if  3 Br  E  Parents(Conflicts(A)).  J,  J  |=*  B' 
then  <7  (A)  <  or(B)  by  condition  2  in  the  definition  of 
refined  stratification,  otherwise  a(B)  <  cr(A)  by  con¬ 
dition  3.  The  case  where  A  is  negative  is  symmetric. 
□ 

Proof  of  Theorem  5.1 

Claim .  For  all  graphs  G  with  vertices  V  there  exists 
a  function  a  :  V  -*  {  1, . . . ,  |V|  }  such  that: 

1.  if  there  is  a  path  from  A  to  B  in  G  then 
er(A)  <  <r(B) ; 

2.  if  <j(A)  =  a(B) ,  then  A  and  B  belong  to  the 
same  strongly  connected  component  of  G. 

To  prove  the  claim,  let  Gi,...,Gn  he  the  strongly 
connected  components  of  G,  and  define  Gi  -<  Gj  iff 
i  7^  j  and  there  is  a  path  in  G  from  a  vertex  of  Gi  to  a 
vertex  of  Gj  .  Note  that  X  is  a  strict  partial  order;  it 


is  well  known  that  every  such  order  can  be  extended 
to  a  strict  total  order  - <°  that  preserves  -< .  Therefore, 
there  exists  a  permutation  z*i , . . . ,  zn  of  1, . . . ,  n  such 
that  Gix  <°  Gi2  . . .  -<°  Gin  .  Now,  for  all  Gik  and 
all  vertices  A  in  Gik  ,  let  a  (A)  —  k.  Clearly,  a  satisfies 
the  above  two  conditions.  This  concludes  the  proof  of 
the  claim. 

Now  let  t  and  l  be  arbitrary  integers  satisfying  the 
assumptions.  Consider  the  function  a  correspond¬ 
ing  to  DG(t ).  The  first  condition  of  compatibility 
with  DG(t)  (namely,  for  all  edges  (A,Z,B)  in  DG , 
a  (A)  <  cr(B))  follows  immediately  from  point  1  of  the 
Claim.  Suppose  that  the  second  compatibility  con¬ 
dition  (if  Z  =  —  then  a  {A)  <  cr(B))  is  violated  for 
some  edge  (A, -,B);  then  cr(A)  =  cr(B)  and  hence, 
by  point  2  of  the  Claim,  A  and  B  belong  to  the  same 
strongly  connected  component.  Therefore,  there  must 
be  a  path  from  B  to  A  which  can  be  extended  to  a 
negative  cycle  by  means  of  (A,  -,B),  contradicting 
the  safeness  of  T.  This  proves  that  a  is  compatible 
with  DG{t ),  and  hence  the  existence  of  7 rt . 

We  are  left  to  show  that  atfi  exists.  Let  DGtj  be 
the  subgraph  of  DG(t)  covering  all  and  only  the  ver¬ 
tices  in  Atj .  The  function  7rt  maps  all  of  these  ver¬ 
tices  onto  the  same  value  l;  therefore,  since  T  is  safe, 
DGtj  contains  no  negative  edges.  Obtain  a  graph  DG 
from  DGt,i  by  removing  all  and  only  the  variable  edges 
(A,v,B)  that  satisfy  one  of  the  following  conditions 

(a)  A  =  A+  and  >3B'  E  Parents(Conflict s(A))  s.t. 

(b)  A  =  AT  and  3 Af  E  Parents(Conflicts(B))  s.t. 

A!  - 

Note  that  if  (a)  (resp.  (b))  holds  for  some  edge 
(A,r,B),  then  (b)  (resp.  (a))  cannot  hold  for  (B,u,  A), 
nor  for  any  (B",z;3  A”)  with  A"  =~g  A  and  B"  =_5 
B .  It  follows  that  DG  cannot  contain  any  pair  of 
edges  (A,v,B)  and  (B\v, A1)  such  that  A*  =-g  A 
and  Br  B . 

Let  a  be  a  function  satisfying  the  conditions  of  the 
Claim  w.r.t.  DG.  Every  positive  edge  (A,  +  ,B)  with 
A,B  E  At,i  belongs  to  DG  by  construction;  there¬ 
fore,  point  1  of  the  Claim  implies  that  a  satisfies  the 
first  condition  of  the  definition  of  refined  stratification 
w.r.t.  .  Secondly,  suppose  that  the  second 

of  such  conditions  is  violated  for  some  edge  (A,  v ,  B) ; 
that  is,  A  =  A+, 

3 Bf  E  Parents(Conflicts(A)).  f=*  B', 

(1) 

■  <t(A)£v{B).  (2) 
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By  (1),  (A,  v,  B)  is  not  eliminated  and  belongs  to  DG] 
then,  by  point  1  of  the  Claim,  a(A)  <  <r(B) ;  con¬ 
sequently,  by  (2),  a{A)  -  a(B) .  This  implies,  by 
point  2  of  the  Claim,  that  DG  contains  a  path  from 
B  to  A .  By  the  second  safeness  condition,  such  path 
must  contain  an  edge  (Bf,v.Af)  such  that  B'  =_5  B 
and  A'  A .  But  this  is  absurd,  because  as  we  have 
already  pointed  out,  DG  should  contain  at  most  one 
of  (A,  v,B)  and  (B',v,A')-  Therefore,  a  must  satisfy 
the  second  condition  in  the  definition  of  refined  strat¬ 
ification.  Symmetrically,  if  the  third  such  condition 
were  violated  by  a  then  a  contradiction  would  follow. 
This  proves  that  a  is  a  refined  stratification  on  Atj 
w.r.t.  M(Mj i)-i .  □ 

Lemma  A. 2  M  C  |  a  . 

Proof  The  following  claims  will  be  needed.  They  fol¬ 
low  easily  from  the  definition  of  and  (for  Claim  1) 
from  the  assumption  that  T  is  safe: 

Claim  1 .  We  say  that  two  interpretations  I  and  J 
agree  until  r  if  for  all  (£,  A)  with  i{t ,  A)  <  r , 

(£,  A)  €  I  <=>  (t,  A)  G  J. 

If  I  and  J  agree  until  r  —  1  then  . 

Claim  2.  Restricting  T  to  Tr  restricts  the  output  of 
,  that  is,  for  all  triples  r  and  all  interpretations 

/,  J , 

Now,  in  order  to  prove  the  theorem,  it  suffices  to 
show  that  for  all  r  >  (0, 0, 0) , 

MrC^^u;,  (3) 

By  induction  on  r.  The  base  case  is  trivial  since 
M(0f0,o)  =  0  •  Induction  step:  suppose  that  (3)  holds 
for  all  r;  <  r  but  not  for  r  (r  >  (0, 0, 0)),  and  let  j  be 
the  least  integer  such  that  t  2  t 

uj  .  It  must  be  j  >  0,  because  t  0(Mr_i)  = 

Mr- 1  C  (by  induction  hypothesis).  But  then 

t  Wr-X)  = 

=  Mr- 1  U  ^Tr~l  1 3-  l(Mr-i))  by  def. 

=  MT- 1  U  1 3  ~  1(A/t_i))  by  Claim  1 

note  that  M  and  Mr_x  agree  until  r  —  1  by 
construction. 

C  Mr_!  U  f  j  —  l(JlfT-x))  by  Claim  2 

C  Mr_i  U  ($ijf  t  ^)  by  minimality  of  j 
and  monotonicity  of 
=  Mr-i  U  f  W  =  t  W 

by  Prop.  4.1  and  induction  hypothesis. 


A  contradiction.  □ 

Proposition  A. 2  Given  a  stratified  TABT ,  consider 
the  iterative  construction  of  the  model  M .  Any  time , 
in  the  construction,  the  validity  of  a  negated  authoriza¬ 
tion  at  a  time  instant  t ,  is  checked  with  respect 

to  two  interpretations  f  k  and  Mr_i,  it  is  the 

case  that  £(t,  A+)  <  r. 

Proof 

It  is  immediate  from  the  definition  of  the  iterative 
process.  □ 

Lemma  A. 3  IfT  is  a  stratified  TAB ,  and ,  for  some 
k  <  to ,  MT ,  Mr _ i  \=t  L,  for  any  authorization  literal 
L ,  then  for  any  r”  >  r,  it  holds  that  |=* 

L. 

Proof  The  lemma  follows  from  the  definition  of 
stratification,  the  monotonicity  of  the  sequence 
Mro ,  MTl , . . . ,  M,  and  Proposition  A. 2. 

□ 

Corollary  A.l  //  T  is  a  stratified  TAB ,  and 
MT,Mr- 1  (=t  F,  where  F  is  any  conjunction  of  autho¬ 
rization  literals ,  then  for  any  r”  >  r,  /or  an?/  k  <  u, 
it  holds  that  f  k(MT"-i),  Mt"-i  (=t  F. 

Lemma  A.4  •f  a  C  M. 

Proof  By  induction  on  a.  Base;  a  =  0.  t  a  = 
0  C  M.  Inductive  hypothesis:  {t\B)  G  t  “  1  => 
(£',B)  G  M,  for  any  authorization  B,  we  prove  that 
(£,  A)  G  $2^  t  a  =>  (£,  A)  G  M,  for  any  authorization 
A.  Let  r  =  .£(£,  A)  in  the  considered  dynamic  strati¬ 
fication  of  T.  By  cases  on  the  rule  applied  to  derive 
(t,  A)  in  t<2. 

rule  A  (77,  P,  A)  G  T,  and  t  G  SoJ(T/,P). 
(TJ,  P,A)  G  Tr  (definition  of  stratification),  and 
then  ( t,A )  G  f  l(Mr_i)  (by  definition  of 

the  operator  $),  therefore  (i,  A)  G  Mr  C  M. 

rule  B  (T7,  P,  A  whenever  F)  G  T,  t  G  Sol(TI,P)7 
and  t  -  1,  M  (=4  P. 

Let  F  = 

We  prove  that  there  exists  k  <u  such  that 
t  k{Mr-i),Mr-i  N  F. 

In  particular,  we  prove  that  there  exists  k  <  u 
such  that 

t  k(Mr-i),Mr-i  K  -’Bi,  for  all  1  <  i  < 

n,  and 
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t  k(Mr-i),Mr-i  K  Cj,  for  all  1  <  j  < 
m. 

Consider  any  Bi. 

t  a  —  1,  M  \=t  ‘"'Bi,  from  the  hypothesis. 

•  If  Bi  =  B+,  then  either  (i)  (£,  Bi)  &  M,  or 
(ii)  3 D~  €  Conflicts(^j)  such  that  (£,  D~)  £ 

In  the  first  case,  (£,  Bi)  g  Mr_ i  (since 
Mr_i  CM,  by  construction). 

In  the  second  case  (t,D~)  €  t  a  — 
1  ^  (£,  D~)  €  M  (inductive  hypothesis) 
=>  (*,£>“)  €  Mr/,  being  r'  =  £(£,  £)“)  (from 
the  stratification  of  T). 

D~  G  Conflicts^)  =>  3(D“,+,A)  € 
DGr{t),  and  then  IIt(Z)_)  <  II*  (A)  (defi¬ 
nition  of  stratification).  Similarly, 

€  Conflicts(JBi)  =»  3(Z)~,z;,Bi)  G 
DGtW,  &nd  3(i?i,i;,r>“)  G  DGr(t ),  and 
then  n*(.D")  =  n*(I?i). 

Being  Ut(Bi)  <  Ilt(A)  (stratification),  we 
can  conclude  that  II t{D~)  <  nt(A),  and 
then  t1  =  £(t, I>“)  <  £(£,  A)  =  r.  There¬ 
fore,  (£,£>“)  G  Mr-!. 

In  both  cases  (i)  and  (ii),  for  any  k  <  a/,  it 
holds  that 

$£r"1  t  k(MT-i),MT-i  K 

•  If  Bi  =  it  must  be  t  a  —  1,  M  |=t 
-•Bi,  and  then  (*,£,)  0  M.  As  a  conse¬ 
quence,  (t,Bi)  g  Mr_ i,  which  proves  that 

t  fc(Mr_i),  Mr_!  \=t  -Bi. 

Consider  any  Cj. 

•  If  Cj  =  C+,  fQ  -  1,M  | =t  Cj  =* 

(f,Cj)  €  t  a  -  1,  and  V£T  € 

Conflicts(Cj),  (f,  D~)  0  M  (definition  of  va¬ 
lidity). 

(t,Cj)  (t.Cj)  €  M  (in¬ 

ductive  hypothesis)  =>  (t,  Cj)  6  MT»,  with 
t'  =  t(t,Cj),T'  <  r  (stratification  of  T) 

This  proves  that  there  exists  kx  <  u  such 
that  ( t,Cj )  €  ^r_1  tki(Mr-i). 

Besides,  ( t,D~ )  £  M  =>  ( t,D~ )  £  Mr_i, 
and  therefore  f  fci(Mr-i),Mr_i  (=t 

•  If  Cj  =  Cj",  it  must  be  that  (£,  Cj)  G  t 
a  -  1. 


Reasoning  as  in  the  previous  case  we  can 
conclude  that  there  exists  ko  <  u  such  that 
$™T~l  tk>(Mr-i),MT-i  (=t  Cj. 

Globally,  we  can  conclude  that  there  ex¬ 
ists  fc(=  max(k\,  A^))  such  that  f 

A;(Mr-i),Mr-i  (=t  F,  and  then,  by  definition  of 
the  $  operator, 

(t,  A)  €  f  Jfc  +  l(Mr-i)  c  M. 

rule  C  (X7,  P,  A  upon  F)  G  T,  t  G  So/(7Y,P),  and 
3£'  €  Sol(TI,P)  such  that  £'  <  and  t 
a  —  1,M  |=^  F. 

E  f  =  t,  this  case  reduces  to  the  previous  one 
(rule  B ). 

If  tr  <t,  let  P  =  ^(£',  A). 

r'  <  r  =►  t  k{Mr-l),Mr-l  K  F, 

(Corollary  A.l)  and  then  (t,  A)  G  Mr,  by  defini¬ 
tion  of  the  immediate  consequence  operator. 

rule  D  (T7,  P,  A  aslongas  F)  G  T,  t  G  Sol(TI,P ), 
and  V£'  G  Sol(TI,P)  such  that  i7  <  t,  t 
a  —  1,  M  (=f/  F. 

If  t1  =  t  is  the  only  t!  G  5o/(T/,  F)  such  that 
t*  <  ty  this  proof  reduces  to  the  case  of  rule  B. 

Otherwise,  for  any  tr  <  t ,  let  r'  = 

e(t',A).  t  ^.0,^-1  K  f 

K  F- 

Since  P  <  r  it  holds  that  for  any  k  <  oj, 
t  fe(Mr-i),  Afr-i  K  by  corollary  A.l, 
and  then  (t,  A)  G  MT,  by  definition  of  the  imme¬ 
diate  consequence  operator. 

rule  E  3Ai  G  Parents(A)  such  that 

•  $^t(a-l),M|=i^i- 

We  prove  that  there  exists  k  <  u  such  that 
S™;-1  tfe(MT-i),MT_!  1 =t  Au 
Let  A  =  Af. 

$¥Ua-  1  ),M  K  =>  (t,^)  €  t 
a  —  1  and  VB"  €  Conflicts(i4^)(t,B")  0  M, 
by  definition  of  validity. 

( t ,  Ai )  6  $x  t  ot  -  1  =>  (t,Al)  €  M  (in¬ 
ductive  hypothesis)  =*>  {t,A{)  6  MTl,  where 
n  =  £(t,Af).  Since  Ax  €  Parents(yl)  =» 
TX  <  t  (by  definition  of  stratification),  and 
then  (t,Af)  €  tO. 

Besides,  VB~  €  Conflicts(.45h)(t,  B_)  ^ 
M  =>  (t,B~)  &  Mr_x  (monotonicity). 
Therefore,  1 0(Mr_1),MT_1 
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If  A  =  A  ,  the  proof  is  analogous  to  the  first 
part  of  the  above  case. 

•  WI2  €  Conflicts(A),  (£,Ao)  £  M.  Therefore 
(£,  Ao)  &  Mr- 1  (monotonicity). 

•  if  A  =  A+ , 

then  VA3  €  Parents(Conflicts(A)),  T  (a  — 
1), it/  j=t  ~^A3. 

By  definition  of  validity,  it  must  be  (£,  A3)  £ 
M,  and  then  (£,  A3)  ^  Mr_i  (monotonicity). 
Therefore,  |=t  A3. 

Thus,  it  is  proved  that  (£,  A)  €  M. 

□ 

Proof  of  Theorem  5.2  M  is  a  stable  model  of  T  by 
lemmas  A.2  and  A.4.  To  prove  uniqueness,  let  N  be 
any  stable  model  of  T.  Suppose  that  N  ^  M  and  let  f 
be  the  maximal  r  such  that  N  and  M  agree  until  r.  It 
suffices  to  show  that  for  all  i,  f  i  and  t 1  agree 
until  f +1 ,  which  implies,  by  def.  of  stable  model,  that 
M  and  N  agree  until  f  + 1  and  hence  a  contradiction. 

The  proof  is  by  induction  on  i.  The  base  case  is 
trivial.  For  the  induction  step,  note  that  since  T 
is  safe,  the  membership  of  an  arbitrary  (£,A)  with 
£{t,  A)  <  f  +  1  to  t  i  depends  only  on  conditions 
of  the  following  form: 

1.  (*',  A1)  6  t  i  -  1 ,  where  £(£',  A')  <  f  +  1 ; 

2.  (t",A")  £  N ,  where  l{t",A")  <  f. 

By  induction  hypothesis,  f  i  —  1  and  t  i  —  1 
agree  until  f  +  1 ,  therefore  N  can  be  equivalently  re¬ 
placed  by  M  in  point  1;  moreover,  since  N  and  M 
agree  until  f  by  assumption,  N  can  be  equivalently 
replaced  by  M  in  point  2.  It  follows  immediately  that 
(£,  A)  6  Jj!  |  *  implies  (£,A)  £  t  The  op¬ 
posite  implication  can  be  proved  symmetrically.  This 
completes  the  proof.  □ 
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Abstract 

Inference  attacks  mean  that  a  user  infers  (or  tries  to  in¬ 
fer)  the  result  of  an  unauthorized  method  execution  using 
only  authorized  methods  to  the  user.  We  say  that  a  method 
m  is  secure  against  inference  attacks  by  a  user  u  if  there 
exists  no  database  instance  for  which  u  can  infer  the  result 
of  m.  It  is  important  for  database  administrators  to  know 
which  methods  are  secure  and  which  ones  are  not.  When  an 
administrator  finds  that  a  method  which  retrieves  top  secret 
information  is  not  secure  against  inference  attacks  by  u,  the 
administrator  can  prevent  u  from  attacking  the  method  by 
changing  the  authorization  for  u.  This  paper  formalizes  the 
security  problem  ( i.e.,  to  determine  whether  a  given  method 
is  secure  or  not)  for  method  schemas,  and  presents  the  fol¬ 
lowing  results.  First,  it  is  shown  that  the  security  problem 
is  undecidable.  Next,  a  decidable  sufficient  condition  for 
a  given  method  to  be  secure  is  proposed .  Furthermore,  it 
is  shown  that  the  sufficient  condition  is  also  a  necessary 
one  if  a  given  schema  is  monadic  (i.e.,  every  method  has 
exactly  one  parameter).  The  time  complexity  to  decide  the 
condition  is  also  evaluated.  For  a  monadic  schema,  the 
condition  is  decidable  ( and  therefore,  the  security  problem 
is  solvable)  in  polynomial  time  of  the  size  of  the  schema. 

1  Introduction 

In  recent  years,  various  authorization  models  for  object- 
oriented  databases  (OODBs)  have  been  proposed  and  stud¬ 
ied.  Among  of  them,  the  method-based  authorization 
model  [5,  13]  is  one  of  the  most  elegant  models  since 
it  is  in  harmony  with  the  concept  that  “an  object  can 
be  accessed  only  via  its  methods”  in  the  object-oriented 
paradigm.  In  the  model,  an  authorization  A  for  a  user  u  can 
be  represented  as  a  set  of  expressions  m(ci , . . . ,  cn),  which 
means  that  u  can  directly  invoke  method  m  on  any  tuple 
(o\ , . . . ,  on)  of  objects  such  that  Oi  is  an  object  of  class  c» 
(1  <  i  <  n).  On  the  other  hand,  even  if  m(ci  ,...,cn)  0  A, 


u  can  invoke  m  indirectly  through  another  method  execu¬ 
tion  in  several  models  (e.g.,  protection  mode  in  [3]).  Al¬ 
though  such  indirect  invocations  are  useful  for  data  hid¬ 
ing  [3],  they  may  also  allow  inference  attacks  in  some  sit¬ 
uations. 

Example  1:  Let  Employee,  Host,  and  Room  be  classes 
representing  employees,  hosts,  and  rooms,  respectively. 
Suppose  that  a  method  uses  returns  the  host  which  a  given 
employee  uses,  and  a  method  located  returns  the  room  in 
which  a  given  host  is  placed.  Also  suppose  that  a  method 
office,  which  returns  the  room  occupied  by  a  given  em¬ 
ployee,  is  implemented  as  office(x)  =  located(uses(x)). 

Now  suppose  that  the  physical  computer  network  is  top 
secret  information.  In  this  case,  an  authorization  for  a 
user  u  may  be  the  one  shown  in  Fig.  1,  where  a  solid 
(resp.  dotted)  arrow  denotes  an  authorized  (resp.  unautho¬ 
rized)  method  to  u.  Suppose  that  u  have  obtained  that 
uses(John)  =  mars  and  office(John)  =  A626  using  the 
authorized  methods.  Also  suppose  that  u  knows  the  im¬ 
plementation  body  of  office  as  its  behavioral  specification. 
Then,  u  can  infer  that  located(mars)  =  A626. 

On  the  other  hand,  suppose  that  method  uses  re¬ 
trieves  top  secret  information  and  therefore  the  authoriza¬ 
tion  of  u  is  set  as  shown  in  Fig.  2.  Then,  u  knows 
that  located(mars)  =  A626,  office(John)  =  A626,  and 
office(x)  =  located(uses(x)),  similarly  to  the  former  case. 
However,  u  cannot  conclude  that  uses(John)  =  mars  only 
from  the  above  information,  since  there  may  be  another 
host  h  such  that  uses(John)  =  h  and  located(/i)  =  A626.  □ 

For  a  given  database  schema  S  and  an  authorization  A 
for  a  user  u>  an  n-ary  method  m  is  said  to  be  secure  at 
(ci,...,cn)  (each  c*  is  a  class  in  5)  against  inference  at¬ 
tacks  by  u  if  u  cannot  infer  the  result  of  m(ol5...,on) 
for  any  objects  Oi  of  class  C{  in  any  database  instance 
I  of  5,  using  only  authorized  methods  to  u.  Other¬ 
wise,  m  is  insecure .  For  example,  if  uses(  Employee)  and 
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Fig.  1:  An  example  of  an  insecure  method. 


Employee _ 

, _ Host 

s — 

Room  _ 

— 1 

\ 

[  secure  ] 

| 

!  ,  ,  uses 

j  John  *  mars 

located 

_A626 

i 

i 

j  \ 

r 

i 

y 

! 

i 

office 

1 

i 

1 

1 _ L_ 

L 

1 

Fig.  2:  An  example  of  a  secure  method. 


office(Employee)  are  authorized,  then  located  is  insecure 
since  the  user  can  infer  located(mars)  =  A626  under  the 
database  instance  shown  in  Fig.  1.  On  the  other  hand,  it  will 
be  shown  later  that  uses  is  secure  when  only  located(Host) 
and  off ice( Employee)  are  authorized.  It  is  important  for 
database  administrators  to  know  which  methods  are  secure 
and  which  ones  are  not.  When  an  administrator  finds  that 
a  method  which  retrieves  top  secret  information  is  insecure 
against  inference  attacks  by  u ,  the  administrator  can  pre¬ 
vent  u  from  attacking  the  method  by  changing  the  autho¬ 
rization  for  u . 

In  this  paper,  we  formally  define  the  security  problem, 
i.e.,  to  determine  whether  a  given  method  is  secure  or  not. 
We  adopt  method  schemas  proposed  by  [2]  as  a  formal 
model  of  OODB  schemas  since  they  support  such  basic 
features  of  OODBs  as  method  overloading,  dynamic  bind¬ 
ing,  and  complex  objects.  The  semantics  is  simply  defined 
based  on  term  rewriting.  Under  this  formalization,  we  first 
show  that  the  problem  is  undecidable.  Next,  we  propose 
a  decidable  sufficient  condition  for  a  method  to  be  secure. 
Furthermore,  we  show  that  the  sufficient  condition  is  also 
a  necessary  one  if  a  given  schema  is  monadic  (i.e.,  ev¬ 
ery  method  has  exactly  one  parameter).  Finally,  we  eval¬ 
uate  the  time  complexity  of  deciding  the  condition.  For 
a  monadic  method  schema,  the  proposed  condition  is  de¬ 
cidable  (and  therefore,  the  security  problem  is  solvable)  in 
polynomial  time  of  the  size  of  the  schema. 

The  main  idea  of  the  proposed  sufficient  condition  is 
to  “conservatively”  approximate  the  user’s  inference.  The 


user's  inference  is  object-level,  while  the  approximation  is 
class-level  inference.  To  do  the  class-level  inference,  we 
use  a  static  type  checking  technique  for  method  schemas. 
Let  m  be  an  n-ary  method  and  c\,. . . ,  cn  be  classes.  The 
most  difficult  task  in  type  checking  is  to  solve  the  following 
question: 

Suppose  that  m  is  executed  on  arbitrary  ob¬ 
jects  oi,. . . ,  on  such  that  ox-  belongs  to  class 
C{.  What  class  does  the  object  obtained  by  the 
execution  belong  to? 

Unfortunately,  this  question  is  unsolvable  in  general  [2]. 
However,  the  type  checking  algorithm  proposed  in  [12] 
can  compute  a  set  of  classes  which  contain  all  the  correct 
classes,  although  the  set  may  contain  some  wrong  classes. 
Using  this  algorithm,  we  can  conservatively  approximate 
user’s  inference. 

In  this  paper  we  discuss  precise  inference  in  OODBs. 
Precise  inference  means  that  a  user  can  infer  (or,  is  inter¬ 
ested  in)  only  the  exact  value  of  the  result  of  an  unautho¬ 
rized  method.  On  the  other  hand,  most  of  the  recent  re¬ 
searches  concentrate  on  imprecise  inference  in  relational 
databases,  not  OODBs.  Imprecise  inference  means  that  a 
user  can  infer  (or,  is  interested  in)  possible  values  of  the  re¬ 
sult  of  an  unauthorized  method  (query)  with  a  certain  prob¬ 
ability.  In  [6],  FD-based  imprecise  inference  involving  ab¬ 
duction  and  partial  deduction  is  discussed.  In  [15],  a  quan¬ 
titative  measure  of  inference  risk  is  formally  defined.  Im¬ 
precise  inference  with  external,  common  sense  knowledge 
can  be  regarded  as  data  mining  [7, 11]. 

[14]  focuses  on  both  precise  and  imprecise  inference  in 
OODBs.  Besides  inferability  of  the  result  of  a  method  ex¬ 
ecution,  the  article  introduces  the  notion  of  controllability, 
which  means  that  a  user  can  control  (alter  arbitrarily)  an 
attribute-value  of  an  object  in  a  database  instance.  We  do 
not  consider  controllability  since  our  query  language  does 
not  support  update  operations  for  database  instances.  How¬ 
ever,  since  our  query  language  supports  recursion  while  the 
one  in  [  14]  does  not,  detecting  inferability  in  our  formaliza¬ 
tion  is  not  trivial.  [14]  also  proposes,  for  a  given  database 
schema  5  and  an  authorization  A ,  a  sound  algorithm  for  de¬ 
tecting  inferability  or  controllability.  However,  [14]  does 
not  evaluate  the  complexity  of  the  algorithm. 

This  paper  is  organized  as  follows.  In  Section  2,  we  give 
the  definition  of  method  schemas.  In  Section  3,  we  discuss 
inference  attacks  and  formulate  the  security  problem.  We 
also  show  that  the  problem  is  undecidable.  In  Section  4, 
we  propose  a  sufficient  condition  for  a  method  to  be  secure. 
Finally,  in  Section  5,  we  conclude  this  paper. 
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2  Method  Schemas 

2.1  Syntax 

We  introduce  some  notations  before  defining  the  syn¬ 
tax  of  method  schemas.  Let  F  be  a  family  of  disjoint 
sets  F0,  F\ ,  F2„ where  Fn  (n  =  0,1,2,...)  is  a  set 
of  function  symbols  of  arity  n.  For  a  countable  set  X 
of  variables,  let  TF(X)  denote  the  set  of  all  the  terms 
freely  generated  by  F  and  X.  For  a  set  V,  let  Vn 
denote  the  Cartesian  product  V  x  •  •  •  x  V.  For  a  term 

N - v - / 

t  E  Tf{X\  an  n-tuple  t  =  €  (TF(X))n 

of  terms,  and  an  n-tuple  x  =  (xi,...,xn)  E  Xn  of 
variables,  let  £[t/x]  denote  the  term  obtained  by  simul¬ 
taneously  replacing  every  x;  in  t  with  ti  (1  <  i  < 
n).  For  example,  f(xi,g(xux2))[(f(a\xl)/(xux2)]  = 
/(/(a),  g(f(a ),  x{)).  For  a  term  t,  define  the  set  of  occur¬ 
rences  R(t)  as  the  smallest  set  of  sequences  of  positive  in¬ 
tegers  with  the  following  two  properties: 

•  e  E  R(t),  where  e  is  the  empty  sequence. 

•  If  r  E  R(U),  then  i  ■  r  E  R(f(tu  •• .  ,tn))  (1  <  i  < 
n),  where  the  center  dot  represents  the  concate¬ 
nation  of  sequences. 

An  occurrence  of  t  specifies  (the  position  of)  a  subterm  of 
t  For  example,  1  •  2  of  /(/(x,£(x)),0(x)))  specifies  the 
first  g(x).  The  replacement  in  t  of  t!  at  r,  denoted  t[r  ♦— £'], 
is  defined  as  follows: 

•  t[e  <—  tf ]  =  t'; 

•  <-t'] 

=  fit l >  •  •  *  j  ti— i  j  t{[r  *  t  ],  , . . . ,  tn), 

where  1  <  i  <  n. 

For  example, 

/(/(x,  g{x)\  g{x))[  1  -  2  <-  h(a,  b )]  =  /(/(*,  h(a,  b)\  g(x)). 

We  go  on  to  the  definition  of  method  schemas.  Let  C 
be  a  finite  set  of  class  names  (or  simply  classes)  and  M 
a  family  of  mutually  disjoint  finite  sets  Af0,  Mi,  M2,. . . , 
where  Mn  (n  =  0, 1 , 2, . . .)  is  a  set  of  method  names  of  arity 
n.  Each  Mn  is  partitioned  into  Mb,n  and  MCjn:  Each  mb  6 
M"b  (=  [Jn>o  ^byn)  (resp.  77lc  E  Me  (~  Un>o  ^c,n))  is 
called  a  base  method  name  (resp.  composite  method  name). 
Furthermore,  each  m  E  M  (=  Mb  U  Mc)  is  simply  called  a 
method  name .  We  say  that  M  is  a  method  signature. 

Hereafter,  we  often  use  a  boid  letter  v  to  mean 
(vi, . . . ,  vn)  without  explicitly  defining  it  when  n  is  irrel¬ 
evant  or  obvious  from  the  context. 


Definition  1:  Let  c  E  Cn.  A  base  method  definition  of 
mb  E  Mb?n  at  c  is  a  pair  (mb(c),c),  where  c  E  C.  A 
composite  method  definition  of  mc  E  Mc>n  at  c  is  a  pair 
(mc(c),  t),  where  t  €  Tm({zi  ,  •  •  • ,  xn}>.  O 

Let  Oi  be  an  object  of  class  cz-  (1  <  i  <  n)  (see  Defs.  2 
and  4  for  formal  definitions).  Informally,  the  above  base 
method  definition  declares  that  the  application  of  mb  to 
o  =  (ou . . . ,  on)  results  in  an  object  of  c  or  its  subclass, 
while  the  above  composite  method  definition  states  that  the 
application  of  mc  to  o  results  in  term  rewriting  starting  from 
£[o/x].  The  formal  definition  is  presented  in  Section  2.2. 

Definition  2:  A  method  schema  [1,  2]  S  is  a  5-tuple 
(C,  <,M,Zb,£c),  where: 

1.  C  is  a  finite  set  of  class  names. 

2.  <  is  a  partial  order  representing  a  class  hierarchy. 
When  c'  <  c,  we  say  that  c'  is  a  subclass  of  c  and  c  is 
a  superclass  of  c'.  We  naturally  extend  <  to  n-tuples 
of  classes  as  follows:  For  two  tuples  c  =  (ci, . . . ,  cn) 
and  c'  =  (c[ , . . . ,  cfn)y  we  write  c  <  c'  iff  a  <  c[  for 
all  i. 

3.  M  is  a  method  signature. 

4.  Eb  is  a  set  of  base  method  definitions. 

5.  Zc  is  a  set  of  composite  method  definitions. 

For  each  possible  combination  c  E  Cn  and  m  E  M„,  there 
must  exist  at  most  one  method  definition  of  m  at  c.  If  every 
method  of  S  has  exactly  one  parameter,  then  S  is  monadic . 

□ 

Example  2:  An  example  of  a  method  schema  S\  is  shown 
in  Fig.  3.  Manager  is  a  subclass  of  Employee,  and  Server  is 
a  subclass  of  Host.  Method  boss(e)  returns  the  direct  boss 
of  employee  e,  and  method  supervisor(e)  returns  the  “sec¬ 
ond  least  manager”  among  the  indirect  bosses  of  e.  Since 
every  method  has  arity  one,  S\  is  monadic.  □ 

2.2  Semantics 

Method  definitions  are  inherited  along  the  class  hierar¬ 
chy. 

Definition  3:  Let  5  =  (C>  <,  M,  2b,  2C),  mb  E  Mb>n,  and 
c  E  Cn.  Suppose  that  (mb(c')>  d)  E  Zb  is  the  base  method 
definition  of  mb  at  the  smallest  c'  above  c,  i.e.,  whenever 
(mb(c//),  c")  E  2b  and  c  <  c;\  it  is  the  case  that  c'  <  c". 
We  define  the  resolution  Res(mh( c))  of  mb  at  c  as  c'.  If 
such  a  unique  base  method  definition  does  not  exist,  then 
Res(mb( c))  is  undefined ,  denoted  ±.  The  resolution  of  a 
composite  method  is  defined  in  the  same  way.  □ 
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C  =  {Employee,  Manager,  Host,  Server,  Room} 

Manager  <  Employee,  Server  <  Host 
M  =  {boss,  uses,  located,  supervisor,  office} 

Zb  =  {(boss(  Employee),  Employee), 

(boss(Manager),  Manager), 

(uses(  Employee),  Host), 

(located(Host),  Room)} 

Zc  =  {(supen/isor(Employee),supervisor(boss(zi))), 
(supervisor(Manager),  boss(a:i)), 

(office(  Employee),  located(uses(xi )))} 

Fig.  3:  A  method  schema  Sj. 

Example  3:  Consider  schema  S\  shown  in  Fig.  3.  By 
Def.  3,  /tey(located(Server))  =  Room.  In  other  words,  class 
Server  inherits  method  definition  (located(Host),  Room)  € 
Zb-  On  the  other  hand,  tfey(boss(Server))  =  J_  since  no  su¬ 
perclass  of  Server  has  a  definition  of  boss.  □ 

The  semantics  of  a  method  schema  is  defined  as  follows. 
To  each  class  name,  a  set  of  objects  is  assigned.  Also,  to 
each  base  method  name  mb,  a  mapping  over  appropriate 
sets  of  objects  is  assigned  as  its  interpretation.  The  seman¬ 
tics  of  a  composite  method  is  defined  by  the  interpretation 
of  base  methods  and  term  rewriting. 

Definition  4:  An  interpretation  (or,  also  called  a  database 
instance)  of  a  method  schema  S  is  a  pair  I  =  (i/,  p)  with 
the  following  properties: 

1.  To  each  c  £  Cyv  assigns  a  finite  disjoint  set  i /(c)  of 
object  identifiers  (or  simply,  objects).  Each  o  £  i /(c) 
is  called  an  object  of  class  c.  Let  Oj  =  [jceC  v{c). 
For  c  =  (ci , . . . ,  cn),  let  i/(c)  denote  v(c\)  x  •  •  •  x 
v(cn)- 

2.  For  each  mb  €  Mb,n»  Mmb)  is  a  partial  mapping 
from  Oj  to  O i  which  satisfies  the  following  two  con¬ 
ditions.  Let  c,  c f  £  C71. 

(a)  If  /tey(mb(c))  =  c',  then  p(mb)  |t,(C)  is  a  total 
mapping  to  |JC<C,  Kc),  where  “|”  denotes  that 
the  domain  of  p  is  restricted  to  i/(c). 

(b)  If  Res(mb(c))  =  _L,  then  p(mb)  is  undefined  ev¬ 
erywhere  in  i/(c).  □ 

A  term  in  Tm(Oj)  is  called  an  instantiated  term.  That 
is,  an  instantiated  term  consists  of  method  names  in  M  and 
objects  in  Oj.  The  one-step  execution  relation  — on  the 
instantiated  terms,  based  on  the  leftmost  innermost  reduc¬ 
tion  strategy,  is  defined  as  follows: 


Definition  5:  Let  m(o)  (o  6  ^(c))  be  the  subterm  of  t  £ 
Tm(Oi)  at  the  leftmost  innermost  occurrence  r. 

1.  If  m  £  Mb  and  Res(m( c))  4  -U  then 

t  -►/  t[r  «-  /i(m)(o)]. 

2.  If  m  £  Mq  and  Res(m( c))  =  t’  4  -U  then 

t  — +/  t[r  <—  £'[o/x]].  □ 

Note  that,  by  Def.  5,  for  any  instantiated  term  t ,  there  ex¬ 
ists  at  most  one  term  t!  such  that  t  — ►/  4 .  That  is,  every 
execution  is  deterministic. 

Let  — +J  be  the  reflexive  and  transitive  closure  of  — >/.  If 
t  tr  and  there  exists  no  t"  such  that  t!  tf\  then 
t!  is  called  the  execution  result  of  tf  and  we  write  ti  =  tr. 
If  €  O/,  then  the  execution  of  t  is  successjul ,  and  if 
4  Oj  because  of  nonexistence  of  the  resolution,  then  the 
execution  of  t  is  aborted.  In  both  cases  (i.e.,  if  t[  exists), 
the  execution  of  t  is  terminating .  On  the  other  hand,  if  £} 
does  not  exist,  then  the  execution  of  t  is  nonterminating . 
We  omit  the  subscript  I  and  simply  write  or  — ►*  if  I  is 

understood  from  the  context. 

Example  4:  An  example  of  an  interpretation  7j  =  (v\,p\) 
of  S\  is  shown  in  Fig.  4.  v\  is  represented  by  gray  rectan¬ 
gles,  e.g.,  v\  (Employee)  =  {Alice,  John}.  p\  is  represented 
by  arrows,  e.g.,  jxi(boss)(John)  =  Alice,  p\  (uses)(John)  = 
mars.  By  Def.  5,  supervisor(Alice)  is  executed  as  follows: 

supervisor(Aiice)  — supervisor(boss(Alice)) 

— supervisor(Sara) 
boss(Sara) 

Bob. 

Thus  supervisor(A!ice)i  =.  Bob.  □ 

3  Inference  Attacks 
3.1  Authorization 

Various  sophisticated  method-based  authorization  mod¬ 
els  for  OODBs  have  been  proposed.  In  this  paper,  however, 
discussing  authorization  models  is  not  our  main  purpose, 
and  therefore  we  adopt  the  following  simple  but  general 
authorization  model. 

Definition  6:  Let  S  =  (C,  <,  M,  Zb,  Zc).  An  authorization 
A  for  a  user  u  under  5  is  a  finite  set  of  m(c),  where  m  £ 
Mn  and  c  £  Cn.  Intuitively,  m(c)  £  A  means  that  u  is 
authorized  to  directly  invoke  method  m  on  any  tuple  o  of 
objects  such  that  o  £  v(c).  O 

An  authorization  is  often  modeled  as  a  pair  of  a  base  au¬ 
thorization  and  a  set  of  inference  rules.  An  example  of  an 
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Fig.  4:  An  interpretation  I\  of  S\. 


inference  rule  is  “if  u  is  authorized  to  invoke  m  on  objects 
of  c,  then  u  is  also  authorized  to  invoke  m  on  objects  of  the 
subclasses  of  c.”  When  c\  <  c  and  C2  <  c,  the  base  autho¬ 
rization  {m(c)}  is  expanded  into  (m(c),  m(ci),m(c2)}  by 
this  rule.  In  this  paper,  we  assume  that  a  given  authoriza¬ 
tion  has  already  been  expanded. 

Example  5:  Define  an  authorization  A\  for  a  user  u  under 
S\  in  Fig.  3  as  follows: 

A\  -  (uses(Employee), 

supervisor(Employee), 

supervisor(Manager), 

office(Employee), 

office(Manager)}. 

Consider  the  interpretation  7i  in  Fig.  4.  Executing 
office(John)  by  u  is  permitted  since  John  £  vx  (Employee) 
and  off ice( Employee)  £  A\ .  On  the  other  hand,  execut¬ 
ing  uses(Sara)  is  prohibited  since  Sara  £  ^(Manager)  but 
uses(Manager)  £  Ax.  □ 

3.2  Formal  Definition  of  User’s  Inference 

In  this  paper,  information  provided  by  a  database  is  mod¬ 
eled  as  a  set  of  (in)equalities.  For  example,  suppose  that  a 
user  u  executes  office(John)  and  obtains  the  result  A626.  In 
this  case,  the  information  that  u  obtains  is  office(John)f  = 
A626.  In  what  follows,  we  demonstrate  that  user’s  infer¬ 
ence  can  be  formalized  as  the  congruence  closure  of  a  fi¬ 
nite  set  of  ground  equalities  when  the  two  reasonable  con¬ 
ditions  (Ql)  and  (Q2)  stated  below  are  satisfied. 

First  of  all,  we  define  the  information  which  u  can  obtain 
directly  from  a  database  instance  1  =  (i/,  /i). 


(*1)  User  u  obtains  m(o)i  =  o  iff  it  is  the  case  that 
m(c)  £  A,  o  £  v{ c),  and  m(o)i  =  o  £  O/.  That 
is,  u  knows  what  the  result  of  771(0)  is  if  executing 
m(o)  is  authorized  and  the  execution  is  successful. 

(*2)  User  u  obtains  Res(m( c))  =  t  iff  it  is  the  case  that 
m(c)  £  A  and  Res(m( c))  =  t.  That  is,  u  knows  the 
type  declaration  of  m  at  c  (when  m  is  a  base  method) 
or  the  behavioral  specification  of  m  at  c  (when  m  is 
a  composite  method),  if  executing  m(o)  (o  £  z/(c))  is 
authorized. 

In  Example  1,  (*1)  and  (*2)  are  stated  informally. 

Next,  suppose  that  u  can  use  at  least  four  inference  rules: 
reflexivity,  symmetry,  transitivity,  and  substitutivity  (i.e.,  if 
ti  =  t •  for  all  i,  then  /(t)  =  /(t')>.  Also  suppose  that  user 
u  knows  that  o  4  o'  for  distinct  objects  o  and  o'  (e.g.,  u 
knows  John  4  Alice,  Sara  4  A626,  and  so  on). 

As  stated  in  Section  1,  the  goal  of  inference  attacks  is  to 
obtain  o  such  that  m(o)X  =  o  for  some  m  and  0.  In  other 
words,  u  wants  to  infer  equalities.  Therefore,  if  we  find  a 
reasonable  condition  under  which  inequalities  are  useless 
to  infer  equalities,  we  can  formalize  user’s  inference  as  the 
congruence  closure  of  equalities  induced  by  (*I)  and  ( *2 ). 
Let  us  examine  the  following  example: 

Example  6:  Recall  the  second  case  of  Example  1,  where 
u  cannot  infer  uses(John)|  =  mars  since  there  may  be  an¬ 
other  host  h  such  that  uses(John)f  =  h  and  located(h)  j  - 
A626.  However,  if  u  knows  that  located(o)i  4  A626  for 
any  other  object  o  in  the  database  instance ,  then  u  can  con¬ 
clude  that  uses(John)  =  mars.  □ 

The  above  example  suggests  that  inequalities  are  useless  to 
infer  equalities  if  the  following  condition  is  satisfied: 

(Ql)  User  u  does  not  know  what  Oj  is. 

In  many  cases,  this  condition  is  satisfied  by  just  hiding  0/ 
from  the  user. 

Equalities  obtained  by  (*2)  are  not  ground  (i.e.,  include 
variables).  However,  together  with  the  following  condi¬ 
tion  (Q2),  they  are  equivalent  to  a  finite  set  of  ground  equal¬ 
ities,  which  has  many  good  properties: 

(Q2)  The  user  does  not  know  what  C  is. 

This  condition  is  also  satisfied  by  just  hiding  C. 

Example  7:  Consider  a  schema  with  a  composite  method 
mc  which  has  the  same  resolution  t  at  every  class  c  £  C. 
Let  A  =  {mc(c)  |  c  £  C}  be  an  authorization  for  a  user  ti. 

Assume  that  u  knows  what  C  is.  Then,  u  can  infer  that 
™c(*;)i  =  t[t*/x] |  for  any  term  tf  such  that  t'J,  £  Oj,  since 
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mc  has  the  same  resolution  t  at  any  class.  Note  that,  in  this 
inference,  u  does  not  need  to  know  which  class  t'[  belongs 
to. 

On  the  other  hand,  if  (Q2)  is  satisfied,  then  u  cannot  con¬ 
clude  that  mc(t/)i  =  t[t'/x]l  without  exactly  inferring  the 
class  to  which  tf  J.  belongs  since  there  may  be  another  class 
c  in  C  such  that  £  u(c)  and  Res(mc(c))  ^  t.  □ 

Type  checking  [2,  12]  is  useless  when  (Q2)  is  satisfied. 
Therefore,  to  know  the  class  to  which  tf  l  belongs  is  to  infer 
the  exact  value  Thus,  the  equalities  obtained  by  (*2) 
can  be  applied  only  to  terms  tf  such  that  tfi  is  known.  This 
means  that  each  equality  Res{mc{ c))  =  t  obtained  by  ( *2 ) 
can  be  regarded  as  {mc(o)J,  =  f[o/x]J,  |  o  £  ^(c)},  which 
is  a  finite  set  of  ground  equalities. 

Consequently,  by  assuming  (Ql)  and  (Q2),  we  can 
model  user's  inference  as  the  congruence  closure  of  a  finite 
set  of  ground  equalities  induced  by  (*  1)  and  (*2).  For  tech¬ 
nical  reasons,  we  define  the  congruence  closure  through 
rewriting  rules  >jjA  introduced  below.  From  the  correct¬ 
ness  of  Knuth-Bendix  completion  [10],  =  o  iff  t  is  re¬ 

ducible  too  by  >J,A- 

Definition  7:  Define  Pj,A  as  the  minimum  set  of  rewriting 
rules  t>iiA  on  Tu  (Oj)  satisfying  the  following  three  con¬ 
ditions.  Intuitively,  t  >i,a  o  means  that  the  user  knows  or 
can  infer  that  1 1  =  o . 

(A)  If  m(c)  £  A,  0  6  v(c\  and  m(o)|  =  o  £  Oj,  then 
PjyA  contains 

m(o)  >j,a  o. 

This  corresponds  to  (*1). 

(B)  If  mc(c)  €  A,  mc  €  Mc,  o  €  i/(c),  mc(o)l  =  o  £  Oj, 
and  Res(mc( c))  =  1 4  -L  then  PjyA  contains 

t[ o/x]  >I,AO. 

This  essentially  corresponds  to  (*2). 

(C)  If  PiyA  contains  t  >jyA  0  and  £"  on  such  that 
ttr  is  a  proper  subterm  of  t  at  r",  then  Pi, a  contains 

t[r"^o"}  >/}Ao. 

See  also  Fig.  5.  This  simulates  Knuth-Bendix  com¬ 
pletion  procedure. 

By  definition,  the  right-hand  side  of  each  rule  is  an  object. 
Note  that  the  existence  of  t  >i,a  °  m  -Pr,A  implies  t  o. 

Define  j#  A  as  the  one- step  reduction  relation  by  t>  /,  a  * 
That  is,  t  =^/,a  f7  iff  there  exists  a  subterm  t"  of  t  at  r" 
such  that  tn  t>i,A  o"  £  PjyA  and  t!  -  t[r "  o"].  Let 


Fig.  5:  Condition  (C)  of  Definition  7. 


=>}  A  denote  the  reflexive  and  transitive  closure  of  =>ijA- 
For  readability,  we  often  write  >/  and  P/  instead  of  >/jA 
and  Pi,A*  respectively.  □ 

Example  8:  For  Si  in  Fig.  3,  I \  in  Fig.  4,  and  A\  in 
Example  5,  P/t  is  computed  as  shown  in  Fig.  6.  Rules 
(A1MA10)  are  obtained  by  Def.  7(A),  and  (B1HB8)  by 
Def.  7(B)  with  composite  methods  supervisor  and  office. 
Rules  (Cl)  and  (C2)  are  obtained  by  Def.  7(C).  For  exam¬ 
ple,  (Cl)  is  derived  from  (Al)  and  (B5). 

Rule  (Cl)  indicates  that  the  user  can  infer  that 
!ocated(mars)l  =  A626,  as  stated  in  the  first  case  of  Exam¬ 
ple  1.  Moreover,  rule  (C2)  indicates  that  located  even  for 
a  server  jupiter  can  be  inferred.  Let  r  =  office(boss(Sara)) 
and  t*  =  office(bos$(John)).  Then, 

r  office(Bob)  =»/,  B533. 

Thus  user  u  can  infer  that  rj.  =  B533.  On  the  other  hand,  u 
cannot  infer  the  value  of  r'f  (although  r'|  =  B533)  since 
no  subterm  of  r;  can  be  rewritten  by  the  rules  in  Pjl .  □ 

3 3  The  Security  Problem 

The  notion  of  security  of  methods  discussed  in  Section  1 
is  naturally  extended  to  terms  in  T^(C)  as  follows:  A  term 
r  £  Tm  (0)  is  said  to  be  secure  if  there  exists  no  interpre¬ 
tation  I  =  fi)  such  that  r[o/c]  o  for  any  o  £  i/(c) 
and  o  £  Oi .  Otherwise,  r  is  insecure.  The  security  prob¬ 
lem  is  to  determine  whether  a  given  r  £  Tm(C)  is  secure 
or  not. 

Theorem  1:  The  security  problem  for  method  schemas 
with  methods  of  arity  two  is  undecidable. 

Sketch  of  Proof:  The  type-consistency  problem  is  to  deter¬ 
mine  whether,  for  a  given  method  schema  S,  there  exists  an 
interpretation  of  S  which  causes  an  aborted  execution.  [8] 
shows  that  the  problem  for  method  schemas  with  methods 
of  arity  two  is  undecidable  by  reducing  the  Post’s  Corre¬ 
spondence  Problem  (PCP)  to  the  problem.  In  the  reduc¬ 
tion,  each  interpretation  I  is  regarded  as  a  candidate  for  a 
solution  to  a  PCP.  If  I  is  actually  a  solution,  then  execution 
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Fig.  6:  Contents  of  Pj, . 


of  a  term,  say  m(o),  is  aborted  under  I.  Otherwise,  m(o)  is 
nonterminating.  By  slightly  modifying  the  reduction  in  [8], 
we  can  construct  a  schema  with  the  following  properties: 

•  If  1  is  a  solution,  then  the  execution  of  a  term,  say 
m'(o),  is  successful  under  J. 

•  Otherwise,  ml{o)  is  nonterminating  under  I. 

Let  c  be  the  class  to  which  o  belongs.  Let  A  =  {m'(c)}  and 
r  =  m'(c).  Then,  the  PCP  has  a  solution  iff  there  exists 
I  =  (i/,  such  that  r[o/c]  =>}  o'  for  some  o  and  o'.  □ 

4  Security  Analysis 

4.1  A  Sufficient  Condition 

In  this  section  we  propose  a  decidable  sufficient  con¬ 
dition  for  a  given  term  r  £  Tm(P)  to  be  secure.  The 
main  idea  is  to  introduce  new  rewriting  rules  on  Tm(C) 
which  “conservatively”  approximate  >j,a>  i-e.,  if  r  is  in¬ 
secure,  then  r  is  reducible  to  a  class  c  by  the  new  rewrit¬ 
ing  rules.  Intuitively,  each  t  £  Tm(C)  is  considered  as 
the  set  of  instantiated  terms  {t[o/c]  |  o  €  i/(c)}.  The 
“execution  result”  E(t)  of  t  is  defined  as  follows:  c  £ 


S(boss(Employee))  =  {Employee,  Manager} 
Z(boss(Manager))  =  {Manager} 

£(uses(Employee))  =  {Host,  Server} 
^(usesCManager))  =  {Host,  Server} 

Z(located(Host))  =  {Room} 

^(located(Server))  -  {Room} 
Z(supervisor(Employee))  =  {Manager} 
Z(supervisor(Manager))  =  {Manager} 

Z(office(Emp!oyee))  =  {Room} 

S(office(  Manager))  =  {Room} 

Z(m(c))  -  0  for  any  other  combinations 
of  m  and  c, 

Z(m(t))  =  [J  Z(m(c)) 

c  €Z{t) 

Fig.  7:  Z  for  schema  S j. 

E{t)  iff  there  exists  an  interpretation  I  =  (i/,  fi)  such  that 
t[o/c]i  £  z/(c)  for  some  o  £  u(c).  Unfortunately,  we  can¬ 
not  compute  E  exactly  in  general  [2].  However,  we  can 
compute  Z  :  Tm(C)  — ►  2C  such  that  Z{t)  D  E(t)  for  ev¬ 
ery  t  £  Tm(C)  [  12].  We  use  such  Z  to  approximate  A. 
The  smaller  Z(t)  is,  the  better  approximation  we  have,  al¬ 
though  the  approximation  is  still  conservative  even  when 
Z(t)  =  C  for  all  t.  The  algorithm  in  {12]  gives  a  fairly 
small  Z. 

Example  9:  Using  the  algorithm  in  [12],  we  can  compute 
Z  for  schema  Si  in  Fig.  3.  The  result  is  presented  in  Fig.  7. 
For  example,  Z(boss(Employee))  =  {Employee,  Manager} 
means  that  for  any  object  e  of  Employee,  the  result  of 
boss(e)  is  an  object  of  either  Employee  or  Manager.  Ac¬ 
tually,  the  obtained  Z  is  equal  to  E  in  this  case.  □ 

The  next  definition  introduces  the  new  rewriting  rules 
>syA,z  on  Tm(C)  which  approximate  >/,a- 

Definition  8:  Define  Ps7a,z  as  the  minimum  set  of  rewrit¬ 
ing  rules  t>s,A,z  on  TM (C)  satisfying  the  following  three 
conditions: 

(A)  If  m(c)  £  A ,  then  Ps,a,z  contains 

c)  >s,a7z  c 
for  each  c  £  Z(m( c)). 

(B)  If  mc(c)  £  A,  mc  £  Afc>n,  and  /tes(mc(c))  =  t  ^  JL, 
then  Ps7a}z  contains 

i[c/x]  >S,A,ZC 
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Fig.  8:  Contents  of  Ps,. 


for  each  c  E  Z(t[ c/x]). 

(C)  If  Ps  contains  t  >s7a7z  c  and  t”  >s7a7z  c”  such  that 
t"  is  a  proper  subterm  of  t  at  r7\  then  Ps7a7z  contains 

t[r"  -  c"]  >s7a,z  c' 

for  each  d  E  Z(t[r"  <—  c77]). 

Define  =>s,a,z  as  the  one-step  reduction  relation  by 
>s,a,z •  Let  =>stA,z  denote  the  reflexive  and  transitive 
closure  of  =>s,a,z-  For  readability,  we  often  write  o 5  and 
Ps  instead  of  >s7a7z  and  Ps7a7z,  respectively.  □ 

Example  10:  Fig.  8  presents  the  contents  of  Ps,  for 
schema  S\  in  Fig.  3,  A\  in  Example  5,  and  Z  in  Fig.  7. 
Rules  (AiHAvi)  are  obtained  by  Def.  8(A),  and  (Bi)-(Biv) 
by  Def.  8(B)  with  composite  methods  supervisor  and  office. 
Rules  (Ci)  and  (Cii)  are  obtained  by  Def.  8(C). 

Rule  (Cii)  indicates  that  the  user  may  be  able  to  infer 
the  location  of  a  server.  Moreover,  rules  (Avi)  and  (Bii) 
together  indicate  that  the  user  may  be  able  to  infer  the  office 
of  the  boss  of  a  manager.  Compare  this  with  the  explanation 
in  Example  8.  □ 

The  next  lemma  states  that  each  rule  in  Pj  is  conserva¬ 
tively  approximated  by  a  rule  in  Ps. 

Lemma  1:  If  there  is  an  interpretation  I  =  (2/,  fi)  such  that 
t[o/x]  O7  o  E  P/  for  some  o  E  v(c)  and  o  E  v(c\  then. 
t[ c/x]  >s  c  E  P5* 

Proof:  We  use  induction  on  the  number  of  the  iterations  of 
a  procedure  which  computes  the  least  fixed  point  satisfying 
the  three  conditions  in  Def.  7. 


Basis:  Consider  the  case  that  m(o)  O7  o  (o  E  u{c))  is  ob¬ 
tained  from  Def.  7(A).  Then,  m(c)  E  A,  o  E  z/(c),  and 
m(o)J,  =  o.  Moreover,  c  E  Z(m( c))  from  the  property  of 
Z .  From  Def.  8(A),  Ps  contains  m(c)  >sc  since  m(c)  E  A 
and  c  E  Z{m{ c)).  The  case  that  /?es(mc(c))[o/x]  O7  o  is 
obtained  from  Def.  7(B)  can  be  proved  in  the  same  way. 
Induction:  Suppose  that  £77[o77/x77]  (o"  E  i/(c77))  is  a  proper 
subterm  of  f[o/x]  (o  E  i/(c))  at  r"  and  that  £[o/x]  >/  o 
(o  E  u(c))  and  f//[o'//x//]  >7  o"  (on  €  u(cn))  have  been 
obtained.  Let  Pfo'/x']  =  f[o/x][r"  o"}  (o'  €  ^(c7)), 

and  suppose  that  t7[o7/x7]  >/  o  is  obtained  from  Def.  7(C). 
By  the  inductive  hypothesis,  Ps  contains  both  t[c/x]  t>5  c 
and  t"[c"/x "]  >s  c” .  From  the  definition  of  J7[o7/x7],  we 
obtain  t'[ cr/xr]  =  f[c/x][r"  c77].  Since  t'[ o7/x7]  >7  o  e 

Pi  implies  t'[ o7/x7]J,  =  o,  it  holds  that  c  E  Z(t'[ c7/x7]). 
From  the  above  inductive  hypothesis  and  Def.  8(C),  we  can 
conclude  that  tf[ c'/x7]  >5  c  E  Ps*  □ 

We  have  the  following  theorem: 

Theorem  2:  Let  r  E  Tm(C).  If  there  exists  no  class  c 
such  that  r  =^s,a,z  c»  ^en  r  secure,  i.e.,  there  exists  no 
interpretation  I  =  (v,  p)  such  that  r[o/c]  =>}  A  o  for  any 
o  E  i^(c)  and  o  E  O7. 

Proof:  By  Lemma  1,  it  can  be  easily  shown  that  if  there  is 
I  =  (1/,  fi)  such  that  t[o/x]  =>}  £7[o7/x7]  for  some  o  E  v{c) 
and  o7  E  ^(c7),  then  £[c/x]  tf[ c7/x7).  The  theorem  is 

implied  by  this  fact.  □ 

The  proposed  sufficient  condition  is  obviously  decid¬ 
able,  since  the  right-hand  side  of  each  rule  >s,a7z  is  a  class 
and  therefore  the  “size”  of  the  term  decreases  every  time  a 
rule  is  applied. 

Example  11:  Consider  schema  S\  in  Fig.  3,  and  let  r  = 
office(boss(Employee)).  We  can  conclude  that  r  is  secure 
since  no  subterm  of  r  can  be  rewritten  by  any  rule  PSl  in 
Fig.  8.  □ 

Example  12:  We  said  that  method  uses  is  secure  in  the 
second  case  of  Example  1.  Actually,  it  is  not  diffi¬ 
cult  to  see  that  Ps  has  only  located(Host)  t>s  Room 
and  office(Employee)  t>s  Room.  This  implies  that 
uses(Employee)  is  secure.  □ 

It  is  open  whether  the  undecidability  of  the  security 
problem  stems  only  from  the  uncomputability  of  E.  In 
other  words,  it  is  open  whether  or  not  the  sufficient  con¬ 
dition  in  Theorem  2  is  also  a  necessary  one  when  we  use  E 
as  Z. 
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4.2  Monadic  Case 

When  a  given  schema  is  monadic,  the  algorithm  in  [  12] 
computes  E  in  time  polynomial  of  the  size  of  S.  Moreover, 
when  a  given  schema  is  monadic  and  we  use  E  as  Z,  the 
sufficient  condition  in  Theorem  2  is  also  a  necessary  one. 

Theorem  3:  Let  5  be  a  monadic  schema  and  r  €  Tm(C). 
If  there  exists  a  class  c'  such  that  r  =>~s  A  B  c\  then  r 
is  insecure,  i.e.,  there  exists  an  interpretation  I  such  that 
r[o/c]  A  of  for  some  o  e  v{c)  and  o'  E  Oj. 

Proof:  See  Appendix  B.  □ 

Example  13:  Consider  schema  S\  in  Fig.  3.  Since  Sj  is 
monadic  and  Z  presented  in  Fig.  7  is  equal  to  £,  we  can 
conclude  that  located(Server)  is  insecure  by  rule  (Cii)  in 
Fig.  8.  Moreover, 

office(boss(Manager))  =>Sl  office(Manager) 

=>s,  Room, 

and  therefore  office(boss(Manager))  is  insecure.  □ 

4.3  Complexity 

We  summarize  the  time  complexity  of  deciding  the  suf¬ 
ficient  condition  stated  in  Theorem  2.  Define  the  size  of  a 
term  t  as  |i2(£)|,  i.e.,  the  number  of  occurrences  of  t.  De¬ 
fine  the  description  length  of  2c,  denoted  ||2c||,  as  the  sum 
of  the  size  of  all  t  such  that  (m(c),  t)  €  Ec.  Also,  define  the 
size  of  S,  denoted  ||5||,  as  follows: 

11*11  =  iq  +  |<|  +  |M|  +  |Sb|  +  ||2;||. 

Let  k  be  the  maximum  arity  of  all  the  methods.  The  height 
of  t  is  defined  as  the  maximum  length  of  the  occurrences  in 
R(t).  Let  L  and  H  be  the  maximum  size  and  height  of  all 
t  in  {i  |  (m(c),  t)  e  2c}  U  {r},  respectively. 

By  assuming  L  <  ||S||,  the  total  time  complexity  (in¬ 
cluding  computation  of  Z)  is 

0(kB+lL\\S\\2(\C\  + 1)2*"*'*1  log  ||S||). 

See  Appendix  C  for  details. 

Theorem  4:  For  a  monadic  method  schema,  the  security 
problem  is  solvable  in  polynomial  time  of  the  size  of  the 
schema.  □ 

5  Conclusions 

We  have  formalized  the  security  problem  against  infer¬ 
ence  attacks  on  OODBs,  and  shown  that  the  problem  is  un- 
decidable.  Then  we  have  proposed  a  decidable  sufficient 
condition  for  a  given  method  to  be  secure,  by  introducing 


class-level  inference  (t>s)  which  conservatively  approx¬ 
imates  object-level  inference  ( >/).  We  believe  that  the 
approximation  is  fairly  tight  in  spite  of  its  simple  defini¬ 
tion,  since  the  sufficient  condition  becomes  a  necessary  one 
when  the  given  schema  is  monadic. 

There  are  several  variants  of  the  security  problem.  For 
example,  [9]  discusses  the  instance-level  security.  In  [9],  a 
method  m  is  secure  if  a  user  cannot  infer  the  result  of  m  un¬ 
der  a  given  database  instance.  The  instance-level  security 
problem  is  solvable  in  polynomial  time  in  practical  cases. 

In  several  situations,  imprecise  inference  becomes  pow¬ 
erful  enough  to  cause  serious  problems.  Moreover,  method 
schemas  do  not  seem  a  perfect  model  of  OODB  schemas 
since  they  do  not  support  multi-valued  methods,  update  op¬ 
erations,  and  so  on.  Therefore,  we  intend  to  extend  both 
inference  and  database  models.  Furthermore,  the  security 
of  incomplete  OODB  schemas  should  be  considered,  so 
that  the  security  can  be  checked  in  parallel  with  designing 
OODB  schemas. 
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APPENDIX 

A  Notation  Table 

Tm(X):  the  set  of  all  the  terms  freely  generated  by 
method  signature  M  and  variables  X. 

t[t/x]:  the  term  obtained  by  simultaneously  replacing  ev¬ 
ery  variable  Xi  £  x  in  term  t  with  £*  £  t. 

R(t):  the  set  of  occurrences  of  term  t. 

t[r  <—  £']:  the  replacement  in  term  t  of  t '  at  occurrence  r. 

Res(m( c)):  the  resolution  of  method  m  at  tuple  c  of 
classes. 

0/:  the  set  of  all  the  objects  in  interpretation  I . 

— ►  j:  the  one-step  execution  relation. 


— >  y.  the  reflexive  and  transitive  closure  of  — ►/. 
t[:  the  execution  result  of  t  £  TM (Of). 
t> /jA:  the  rewriting  rules  on  Tm(Oj)  representing  user’s 
inference  on  interpretation  I  under  authorization  A. 
Pt,A'.  the  set  of  rewriting  rules 
=>jiA:  the  one-step  reduction  relation  by  D>/,a* 

=>}  A :  the  reflexive  and  transitive  closure  of 
E(t):  the  “execution  result”  of  t  £  TM(C). 
t>  s,a,z  ’  the  rewriting  rules  on  Tm (P)  representing  user’s 
inference  on  an  interpretation  of  S  under  authoriza¬ 
tion  A,  using  Z  which  approximates  E. 

Ps,a,z:  the  set  of  rewriting  rules  t 
=>s,a,z'<  the  one-step  reduction  relation  by  >syAyz- 
a  z:  reflexive  and  transitive  closure  of  =>s,a,z* 

B  Complete  Proof  of  Theorem  3 

We  introduce  a  syntactic  interpretation  Is  =  {vs,  Ps)  of 
a  monadic  schema  S,  and  show  that  Is  satisfies  Theorem  3. 
Let  N  be  a  positive  integer. 

1.  For  each  c  £  C,  us(c)  =  {c  •  a  |  a  £  C*  and  the 
length  of  c  •  a  is  at  most  N },  where  C~  denotes  the 
Kleene  closure  of  C . 

2.  For  each  mb  £  Afb,  define  ps(mb)  as  follows: 

(a)  If  /tey(mb(co))  =  c',  then  ps(m b)(co)  =  c\  and 
for  j  >  1, 

/is(™b)(c0  *  Cl  *  C2  *  ■  -  Cj) 

Cl  -C2'"Cj  if  Cl  <  c', 

P  •  C2  *  *  •  Cj  otherwise. 

(b)  If  Res(mh(co))  =  -L,  then  ps(mh)(co  •  cj  • 
ci  •  *  •  cj)  (j  >  0)  is  undefined. 

We  consider  a  syntactic  interpretation  Is  =  (ys,  Ps)  with 
sufficiently  large  N. 

In  order  to  prove  that  Is  satisfies  the  theorem,  we  need 
several  technical  lemmas. 

Lemma  2:  Let  t  £  Tm({x}),  and  suppose  that  P  £ 
E(t[c/x]).  There  exists  f3  £  C*  such  that 

1.  the  first  symbol  of  /3  •  P  is  c,  and 

2.  for  each  a  £  C*  such  that  f3  ■  P  *  a  is  an  object  of  Is 
(i.e.,  the  length  of  j3  •  P  *  a  is  at  most  N), 

t[fi  *  P  *  ct/x]  P  •  a. 
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We  call  (3  a  reduction  string  of  (t[c/x],  c7). 

Proof:  Suppose  that  c7  £  E(t[c/x]).  By  the  definition 
of  E ,  there  exists  an  interpretation  I  =  (i/,  /z)  such  that 
t[o/x]  —>j  o'  for  some  o  £  i/(c)  and  o'  £  z/(c7).  Consider 
the  i-th  step  (counting  from  zero)  ti[oi[x]  — ►  /  t,*+1  [oi+1  /x] 
of  the  reduction  t[o/x]  — o',  where  iolPo/z]  =  i [o/aj] 
and  tn[on/x]  =  o'.  Let  c*  (0  <  i  <  n  —  1)  be  the  class 
such  that  Oi  £  z/(c*),  and  mi(oi)  be  the  innermost  term  of 
tiloi/x].  Define  ft  (0  <  i  <  n  -  1)  as  follows: 

0  .  =  f  ci  if  m,- £  Mb, 

\  e  otherwise. 

In  what  follows,  we  show  that  f3  =  /30  *  *  *  /3n-i  satisfies  the 
conditions  of  this  lemma. 

It  is  easily  verified  that  (3  satisfies  the  first  condition 
since 

•  o0  =  o  £  i/(c),  and 

•  if  mi  £  Mc,  then  =  o>i  by  the  definition  of  — >/. 

To  see  that  /?  also  satisfies  the  second  condition,  consider 
the  execution  of  to[j3  ■  c7  •  a/x]  under  Js  for  an  arbi¬ 
trary  a  £  C*.  If  mo  £  Mb,  then  ft  =  Co,  and  thus 
£0[/?*c7-a/x]  ••  «c'*a/x].  On  the  other 

hand,  if  mo  £  MCJlhenft  =  e,  and  thus  to[/3-c' -a/x]  — >js 
1 1  [/3i  •  *  */3n_i  *  c'  •  a/x].  In  either  case, 

f0[/3  •  d  •  a/x]  =  <otAr  A  '  *  *  A»-i  *  ^  •  a/x] 
-*/s  -c'-a/x]. 

By  repeating  this,  t[j3  •  c7  •  a/x ]  — c7  •  a.  O 

Lemma  3:  Let  t,  t\  tn  £  Ta/ ({z})  such  that  tn  is  a  sub¬ 
term  of  t  atr77  and  =  £[r"  x].  If  both  c77  £  P(£"[c/x]) 

and  c7  £  P(i'[c77/x])  hold,  then  c7  £  P(£[c/x]). 

Proof:  By  Lemma  2,  there  exist  reduction  strings  f3 77  of 
(i77[c/x],c77)  and  ft  of  (£7[c77/x],  c7),  i.e., 

•  the  first  symbol  of  ft 7  •  c77  is  c, 

•  -  c77  •  a"/x]  -+Js  c77  •  a77  for  any  a77  £  Cm% 

•  the  first  symbol  of  ft  •  c7  is  c77,  and 

•  i7^7  •  c7  •  a7/x]  — c7  *  a7  for  any  a7  £  C*. 

When  we  choose  a"  so  that  c77  •  a 77  =  ft  -cr  -  a7,  we  have 

t [/?"  •  /37  •  c7  •  a7/x]  ->  J5  c7  •  a7. 

By  the  definition  of  E ,  c7  must  be  in  E(t[c/x]).  □ 

Lemma  4:  Let  t ,  t7,  £77  £  Tm({z})  such  that  i77  is  a 
subterm  of  t  at  r77  and  £7  =  t[r77  <—  x].  Suppose  that 


c77  £  E{tff[cjx])  and  c7  £  P(£7[c7//x]).  Let  ^37  be  an  ar¬ 
bitrary  reduction  string  of  (i7[c77 /x],  c7).  Then,  there  exist 
reduction  strings  (3  of  ( t[c/x],cf )  and  ft1  of  (i77[c/x],c77) 
such  that  (3  =  ft1  ■  /37. 

Proof:  Let  /377  and  ft  be  arbitrary  reduction  strings  of 
(i"[c/x],c77)  and  (i7[c"/x],  c7),  respectively.  By  the  proof 
of  Lemma  3,/3"*/37  is  a  reduction  string  of  (£[c/x],  c7).  This 
fact  implies  the  lemma.  □ 

The  next  lemma  states  that  if  t[c/x]  >5  c7  £  P5,  then 
t[o/x]  >Is  o'  £  P/s  for  some  o  £  i/s(c)  and  o7  £  i/s(c7). 
In  this  sense,  P$  contains  no  “wrong”  rules. 

Lemma  5:  Let  c,  c7  £  C,  and  t  £  TM({x}).  If  t[c/x]  \>s 
c7  £  P5,  then  for  an  arbitrary  reduction  string  /?  of 
(f[c/x],  c7)  and  for  any  a  £  C*\ 

•  c7  *  a/x]  c7  •  a  £  P/s. 

Proof:  We  use  induction  on  the  number  of  the  iterations  of 
a  procedure  which  computes  the  least  fixed  point  satisfying 
the  three  conditions  in  Def.  8. 

Basis :  Suppose  that  m(c)  >s  c7  is  obtained  from  Def.  8(A). 
Let  (3  be  an  arbitrary  reduction  string  of  (m(c),  c7).  Since 
m(c)  £  A  and  m{fi  •  cf  -  a)  -+j5  c7  •  a,  we  obtain 
m(/3  ♦  c7  •  a)  t>Is  c7  •  a  from  Def.  7(A).  The  case  that 
Res(mc(c))[c/x]  >s  c7  is  obtained  from  Def.  8(B)  can  be 
proved  similarly. 

Induction :  Suppose  that  there  exist  c  £  C  and  t,  t\  t"  £ 
TM ({z})  such  that 

•  t,r  is  a  subterm  of  t  at  r77, 

•  t*  =  t[r77  <—  x], 

•  f"[c/x]  >s  c77  £  Ps, 

•  f[c/x]  >s^i  £  Ps  for  some  c\>  and 

•  c7  £  E(t'[c"/x]). 

Also  suppose  that  t![c”fx]  >5  c7  is  obtained  from 
Def.  8(C).  Since  tn[c/x]  t>s  c"  G  Ps ,  it  holds  that 
c77  £  P(f77[c/x])  by  Def.  8.  By  Lemma  3,  it  holds  that 
c7  £  E(t[c/x]).  Then,  by  Def.  8  again,  t[c/x ]  >5  c7 
must  be  in  Ps.  Let  ft  be  an  arbitrary  reduction  string 
of  (t7[c77/x],c7).  That  is,  the  first  symbol  of  ft  •  c7  is  c77 
and  t7[/37  •  c7  •  a7/x]  — c7  ■  a7  for  any  a7  £  C *.  By 
Lemma  4  and  the  inductive  hypothesis  for  t[c/x ]  >s  c* 
and  tN[c/x]  t>s  c'\  there  exist  f3  and  ft 7  such  that 

•  the  first  symbol  of  f3  *  c7  is  c, 

•  t[/3  *  c7  •  a/x]  >/s  c7  •  a  £  Pjs  for  any  a  £  C*, 

•  the  first  symbol  of  ft 7  •  c77  is  c, 
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•  t> i sc" -a"  £  Pis  for  any  a"  €  C\ 
and 

•  /3  =  ft'  -ft. 

When  we  choose  a  and  a"  so  that  ft  •  c7  *  a  =  c77  •  a 77 ,  it 
holds  that  p  -  c'  *  a  =  ft'  •  c"  -  a".  By  Def.  7(C), 

t[fi  -  c  *  a/x][r77  <—  c"  ■  a77]  >/s  d  *  a  £  Pjs. 

Since  £[/?  •  c7  •  cc/x][rn  «—  c"  ■  a7']  =  t7[c"  *  a/7/x]  = 
t'[P 7  •  c7  •  a/x],  Pis  contains  £7[ft  •  d  *  a/x]  t>js  c7  *  a 
for  any  a.  □ 

Finally,  the  next  lemma  states  that  if  t[c/x ]  =>ms 
tr[df/x],  then  t[o/x ]  =>Js  t'[o'f/x]  for  some  o  £  t's(c) 
and  o"  £  i/s(c77). 

Lemma 6:  Let  c,  d  £  C  and  £,  tr  £  7m({x}).  If 
i[c/x]  =^5  f7[c77/x],  then  there  exists  a  string  p  such  that 
the  first  symbol  p  •  c77  is  c  and  for  any  a77  £  C*, 

f[/3  -  c"  •  a,;/x]  t’[c”  •  a77/x]. 

Proof:  We  use  induction  on  the  length  of  the  reduction 
t[c/x]  =>5  f'[c"/x]. 

Bam:  It  is  obvious  when  the  length  of  the  reduction  is  zero. 
Induction :  Consider  the  following  reduction: 

t[c/x]  =>5  ii[Ci/x]  =>5  tf[c,f fx]. 

By  the  inductive  hypothesis,  there  exists  a  string  P x*  such 
that  the  first  symbol  of  ft  •  Cj  is  c  and  for  any  a*  £  C*, 

i[ft  *  Cf  •  Qfj/x]  =^js  *  OLijx\. 

On  the  other  hand,  by  Def.  8,  there  exists  a  subterm  t” 
of  ti  at  r77  such  that  £77[c*/x]  t>s  d*  and  t7[c77/x]  = 
U [Ci / x][r 77  <—  c77] .  By  Lemmas  2  and  5,  there  exists  ft  such 
that  the  first  symbol  of  ft  •  cn  is  Ci  and  for  any  a "  £  C*, 
rule  ^'[ft  •  c"  •  a"/x]  >  j5  c"  ■  a 77  exists  in  Pjs.  By  Def.  7, 
it  follows  that  t"[ft  •  c"  •  an/x]  =$►/<.  c77  •  a77.  Hence, 

it-[ft  •  c77  •  a"/x]  =>Js  i7[c"  •  a77/x]. 

We  can  choose  a*  so  that  ft  •  c77  •  a 77  =  c*  •  a*.  Therefore, 
it  follows  that 

t[pi  *  ft  •  c"  •  a77/x]  =»  *7[c77  •  a7,/x]. 

Clearly,  p  -  ft  *  ft  satisfies  the  condition  of  the  lemma.  □ 
Theorem  3  immediately  follows  from  Lemma  6. 


C  Complexity  Analysis 

The  algorithm  for  deciding  the  sufficient  condition 
stated  in  Theorem  2  consists  of  the  following  three  steps: 

(51)  Compute  Zq  from  S  using  the  type  checking  algo¬ 
rithm  in  [12],  where  Zq  is  a  mapping  Z  whose  do¬ 
main  is  restricted  to  {m(c)  |  m  £  Mn,  c  £  C71}. 

(52)  Compute  Ps,a,z  from  S,  A,  and  Zq. 

(53)  Determine  whether  there  exists  a  class  c  such  that 

r  c'  *f  such  c  exists,  then  output  “t  may 

be  insecure.'"  Otherwise,  output  “r  is  secure.” 

We  analyze  the  time  complexity  of  the  algorithm.  For 
the  reader’s  convenience,  we  explain  the  notation  intro¬ 
duced  in  Section  4.3  again.  Define  the  size  lt  of  a  term  t 
as  \R(t)\y  i.e.,  the  number  of  occurrences  of  t .  Define  the 
description  length  of  Zc,  denoted  ||ZC|J,  as  the  sum  of  lt  for 
all  (m(c),  t)  £  Zc.  Also,  define  the  size  of  5,  denoted  ||5||, 
as  follows: 

||S||  =  |C|  +  |<|  +  |M|  +  |Zb|  +  ||Zc||. 

For  readability,  we  use  N  to  mean  ||S||.  Let  A;  be  the  max¬ 
imum  arity  of  all  the  methods.  The  height  of  t ,  denoted 
ktl  is  defined  as  the  maximum  length  of  the  occurrences  in 
R(t ).  Let  L  and  H  be  the  maximum  size  and  height  of  all  t 
in  {t  |  (m(c),  t)  £  Z<J  U  {r},  respectively.  We  assume  that 
L  <  N,  i.e.,  the  size  of  r  does  not  exceed  the  size  of  S. 

First,  consider  (SI).  The  time  complexity  of  computing 
Zo(m(c))  for  all  m  £  Mn  and  c  £  Cn  is 

0(kN\C\2k+1), 

which  is  given  in  [12].  In  this  type-checking  algorithm,  Zq 
is  implemented  by  a  table,  and  retrieving  an  element  from 
Zq  takes  G(kN\C\k)  time.  In  (SI),  we  also  reconstruct  Zq 
by  a  more  efficient  data  structure  such  as  binomial  heap  [4]. 
The  time  complexity  pz0  of  retrieving  an  element  from  or 
inserting  an  element  into  Zq  becomes 

PZo  =  0(klog(\M\  ■  \C\k))  =  0(k2 log N). 

Note  that  pz0  0(k  log  N\  since  the  keys  are  terms  m(c) 
and  a  key  comparison  takes  0(k )  time.  This  reconstruction 
takes 

0{\M\  •  \C\k(kN\C\k  +  pz„)) 

=  0(feiV|C,|*(2V|C’|*  +  k  log  N)) 

time.  Thus,  the  complexity  of  (SI)  is 

0(ikiV|C’|i!(iV|C'|fc  +  k  log  N)).  (1) 
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T1  Qm  ♦-  0.  Q*  —  0 
T2  compute  Res(m( c))  for  all  m(c) 
T3  for  each  m(c)  in  A 
T4  add  m(c)  to  Q± 

T5  if  m  £  Me  then 

T6  let  t  be  Res(m( c)) 

T7  add  t[c/x]  to  (?A 

T8  while  Qa  ¥  0 
T9  <&  -  0 

T10  for  each  (*,£')  in 


Til 

T12 

T13 

T14 

T15 

T16 

T17 


Qans  X  Qa  U  Qa  X  Qans  U  Qa  X  Qa 

if  t'  is  a  subterm  of  t  at  r  then 

if  Z(t')  has  not  been  computed  then 
compute  Z(t')  from  Zo 
for  each  c'  in  Z(t') 

add  *[r'  «-  o']  to  <?; 

Qans  4 —  Qans  U  Qa»  Qa  QA 
output  Q  ans  2S  Q 


Fig.  9:  Procedure  for  computing  Q. 


Next,  consider  (S2).  Define  Q  =  {£  |  £  >s  c  €  Ps}. 
In  order  to  compute  P5,  it  suffices  to  compute  Q,  since  the 
right-hand  side  of  >5  can  be  computed  from  the  left-hand 
side  and  Z. 

Fig.  9  shows  a  procedure  for  computing  Q.  Suppose 
that  variables  Q^,  QA,  QA,  and  Z  are  implemented  by  bi¬ 
nomial  heaps.  Let  pQxs  denote  the  complexity  of  retrieving 
ah  element  from  or  inserting  an  element  into  Qans-  Define 
Pqa,  pq^  and  pz  in  the  same  way.  Then, 

Pq™  =  PQa  ~  Pq '  =  Pz  -  0(L  log  |Q|), 

where  L  is  for  a  key  comparison. 

Before  analyzing  the  procedure  in  Fig.  9  in  detail,  we 
estimate  |Q|.  Since  it  is  difficult  to  estimate  |Q|  directly, 
we  introduce  a  finite  set  Qo  of  terms  which  possibly  appear 
in  the  left-hand  side  of  >5.  Formally, 

Qo  =  [J  Xt[  c/x]5 

<m(c),t)€£c 

where  Xt  ( t  £  T^{C))  is  defined  as  follows: 

Xc  =  C, 

-  C  U  {m(t!)  |  t[  £  Xti }. 

Intuitively,  Xt  is  the  set  of  all  the  terms  obtained  by  replac¬ 
ing  arbitrary  subterms  of  t  with  arbitrary  classes.  Clearly 


Q  Q  Qo- 

The  size  of  Xt  can  be  obtained  by  solving  the  following 
(in)equalities: 

l*e|  =  \C\, 

\Xmm\  <  \C\  +  U\Xu\. 

t 

If  k  =  I,  then 

\Xt\  <(At+l)|<7|, 

and  therefore, 

IQoI  <  E  l*««/«ll 

(m(c),i)£Zc 

<  E  (^lc/x|  +  D|C| 

(m(c),t)GS c 

=  E  w*iici 

(m(c),t)G^ 

=  Pdl-|c| 

<  JVIC-I,  (2) 

since  lt  =  ht  +  1  if  k  =  1.  Next,  consider  the  case  that 
k  >  2.  For  any  nonnegative  integer  A,  let  Kh  denote  kh  + 
kh~x  +  *  *  •  +  k°.  In  what  follows,  we  show  that 

\xt\<  (iq  +  i)^.  O) 

If  At  =0, then |.Xt|  =  jd7[  <  (|OJ  + 1)-*^°  =  |C|+1.  Suppose 
that  Eq.  (3)  holds  for  any  term  tf  such  that  htf  <  h  for  some 
h  >  0.  Consider  a  term  t  =  m(t')  such  that  ht  =  h  +  1. 
Then, 

\x*\  <  ici+ni^i 

i 

<  |C7|  +  «|C'|  + 

=  |C|  +  (|C|  + 

<  (|C’|  +  1)JC'"'. 

Therefore,  Eq.  (3)  holds  and 

\Qo\  <  E  1^‘lc/xll 

(m(c),t)e2c 

<  E  (i  ci + 

(m(c),l)6Zc 

<  ||2c||(|C|  +  1)*" 

<  J\T(|C|  +  \)Kh 

<  Ar(|C|+l)***‘,  (4) 

using  Kh  <  kH+l  if  fc  >  2.  After  all,  from  Eqs.  (2)  and  (4), 
we  obtain 

M<l<?o|<JV(|C| +  !)*"*'. 
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Let  us  analyze  the  procedure  in  Fig.  9  in  detail.  See  (T2). 
A  straightforward  algorithm  can  compute  Res  in 

Q(kN\C\k)  (5) 

time.  Next,  see  (T3)  through  (T7).  In  (T3),  \A\  <  \M\  * 
|C|*  <  A^CI*.  If  Res  is  implemented  by  an  appropriate 
data  structure,  then  retrieving  an  element  from  Res  takes 

PRes  =  0{k  logflM I  •  |C|fc))  =  0(k2  log  N) 

time  in  (T6).  In  (T7),  computing  t[ c/x]  takes  O(L)  time. 
Therefore,  executing  (T3)  through  (T7)  takes 

0{\A\{pQt  +  log  \MC\  +  pRes  +  L  +  pQJ) 

=  (D(N\C\k(L  log  |Q|  +  k2  log  N)) 

=  C>(kH+lLN\C\k  log  N),  (6) 

using  k  <  L. 

See  (T8)  through  (T16).  By  QA  and  QA>  we  avoid  select¬ 
ing  a  duplicated  pair  of  t  and  t 1  in  (T10).  In  other  words, 
(Til)  through  (T15)  are  executed  at  most  |Q|2  times,  and 
therefore,  (T16)  is  also  executed  at  most  |Q|2  times.  More¬ 
over,  (T13)  is  executed  at  most  \Q\  times,  since  the  condi¬ 
tion  of  (T12)  holds  at  most  \Q\  times. 

In  (Til),  Knuth-Morris-Pratt  string  matching  algo¬ 
rithm  [4]  can  check  in  0(L )  time  whether  t '  is  a  subterm  of 
t.  Constructing  t[r*  c]  in  (T15)  takes  O(L)  time.  Com¬ 
puting  Qans  U  Q  A  takes  Q(L\og  |Qj)  time  [4].  Therefore, 
the  complexity  of  (Til)  through  (T16)  except  (T13)  is 

0(\Q\2(L  +  pz  +  pz  +  \C\(L  +  pQ'J) 

+\Q\2  ■  Llog\Q\) 

=  0(\Q\2  ■  \C\  •  Llog|<5|) 

=  0(kH+lLN2(\C\  +  log  N).  (7) 

On  the  other  hand,  in  (T13),  Z(t)  is  computed  from  Z0  as 
follows: 

Z(m( c))  =  Zo(m(c)), 

=  (J  Z0(m(O). 

ce^(ti)x-x2(t„) 

The  time  complexity  of  computing  Z(t)  is 

CKpzMCf*1)  =  0(k2L\C\k+l  log  N). 

The  total  complexity  of  (T13)  is 

0(\Q\-k2L\C\M  log N) 

=  C(k2LN(\C\  +  l)fc"*‘+*+I  log  N).  (8) 


U1 

,  -  0-  D*  -  {r} 

U2 

while  D&  =/  0 

U3 

D'a*-<D 

U4 

for  each  ( t ,  t")  in  DA  x  Q 

U5 

if  t"  is  a  subterm  of  t  at  r‘ 

U6 

for  each  c"  in  Z{t”) 

U7 

add  t[r"  <-  c") 

U8 

T^ans  4  I-^ans  U  D&,  DA  4 

U9 

if  jD. 

ans  contains  a  class  then 

U10 

output  ‘V  may  be  insecure” 

Ull 

else 

U12 

output  “r  is  secure” 

Fig.  10:  Procedure  for  determining  r  =>$  c. 

Both  of  Eqs.  (5)  and  (6)  are  bounded  by  Eq.  (7).  Further¬ 
more,  Eq.  (8)  is  also  bounded  by  Eq.  (7)  since  k  <  L  <  N. 
Thus,  the  complexity  of  (S2)  is  given  by  Eq.  (7). 

Lastly,  consider  (S3).  Let  D  =  {t  |  r  t}.  Then, 

PI  <  \Xt\  <  |<?o|  =  <3(iV(|C|  +  l)*""), 
since  hT  <  H. 

Fig.  10  shows  a  procedure  for  determining  whether  D 
contains  a  class.  Suppose  that  DA,  DA  are  imple¬ 
mented  by  binomial  heaps.  By  DA  and  DA>  we  avoid  se¬ 
lecting  t  e  D  more  than  once.  Therefore,  (U5)  through 
(U7)  are  executed  at  most  |D|  •  \Q\  times.  (U8)  is  also  ex¬ 
ecuted  at  most  |Z>|  •  \Q\  times.  Retrieving  an  element  from 
or  inserting  an  element  into  D\ ^  takes 

pK  =  0(L  log  p|)  =  0(kE+1  L  log  N) 

time.  Computing  D  U  DA  also  takes  0(Xlog|D|)  time. 
Thus,  executing  (U2)  through  (U8)  takes 

0(\D\  *  \Q\(L  +  pz  +  \C\(L  +  Pd'J) 

+\D\.\Q\-L\og\D\)) 

=  0(\D\  *  \Q\  •  \C\  •  £log|I7|) 

=  0(kH+l  LN\\C\  +  1)2*H*‘+1  log  N).  (9) 

(U9)  can  be  checked  in  C(\D\)  time.  Therefore,  the  time 
complexity  of  executing  (S3)  is  given  by  Eq.  (9). 

By  Eqs.  (1),  (7),  and  (9),  the  time  complexity  of  the  al¬ 
gorithm  is 

0(kB+lLN\\C\  +  l)2fc"*'+1  log  N). 
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Abstract 

Specification  and  reasoning  about  authorization  in 
object-oriented  databases  are  becoming  increasingly 
significant.  Most  of  the  previous  work  in  this  field  suf¬ 
fers  a  lack  of  formal  logic  semantics  to  characterize 
different  types  of  inheritance  properties  of  authoriza¬ 
tion  policies  among  complex  data  objects ,  especially  in 
object-oriented  databases.  In  this  paper,  we  propose  a 
logic  formalization  to  specify  object  oriented  databases 
together  with  associated  authorizations.  Our  formal¬ 
ization  has  a  high  level  language  structure  to  specify 
object  oriented  databases  and  allows  various  types  of 
authorizations  to  be  specified.  Formal  semantics  is 
also  provided  for  our  formalization.  We  also  illustrate 
our  approach  by  going  through  a  sample  database  ex¬ 
ample  and  describing  the  authorization  using  our  for¬ 
malization. 

1  Introduction 

Authorization  specification  in  object  oriented 
databases  is  being  increasingly  investigated  recently 
by  many  researchers  [4,  6,  8,  9].  However,  most  of 
the  work  todate  suffers  from  a  lack  of  formal  logic  se¬ 
mantics  to  characterize  different  types  of  inheritance 
properties  of  authorization  policies  among  complex 
data  objects.  For  instance,  it  is  not  clear  how  to  pro¬ 
vide  a  formal  semantics  of  inheritance  property  of  ac¬ 
cess  control  rights  in  the  context  of  object  oriented 
databases.  Furthermore,  it  is  also  difficult  to  formally 
reason  about  authorizations  associated  with  different 
objects  in  databases. 

The  purpose  of  this  paper  is  to  address  this  issue 
from  a  formal  logic  point  of  view.  In  particular,  we 
propose  a  logical  language  that  has  a  clear  and  declar¬ 
ative  semantics  to  specify  the  structural  features  of  ob¬ 
ject  oriented  databases  and  authorizations  associated 
with  complex  data  objects  in  databases.  Our  formal¬ 
ization  characterizes  the  model-theoretic  semantics  of 
object  oriented  databases  and  authorizations  associ¬ 
ated  with  them.  A  direct  advantage  of  this  approach  is 


that  we  can  formally  specify  and  reason  about  autho¬ 
rizations  on  data  objects  without  loosing  inheritance 
and  abstraction  features  of  object  oriented  databases. 
We  first  propose  a  logical  language  for  specifying  ob¬ 
ject  oriented  databases.  This  language  has  a  high  level 
syntax  and  its  semantics  shares  some  features  of  Kifer 
et  aV s  F-logic  [7].  We  then  extend  this  language  for 
authorization  specification.  The  semantics  of  the  re¬ 
sulting  language  is  defined  in  such  a  way  that  both  the 
inheritance  property  in  an  object  oriented  database 
(OODB)  and  authorization  rules  among  different  data 
objects  can  be  formally  justified. 

The  paper  is  organized  as  follows.  In  section  2,  we 
first  propose  a  formal  language  £  that  can  be  used  to 
specify  object  oriented  databases.  A  model-theoretic 
semantics  of  £  is  also  provided  in  this  section.  In  sec¬ 
tion  3,  we  extend  £  to  language  £a  by  combining  au¬ 
thorization  specification  associated  with  data  objects 
into  a  database.  The  semantics  of  £a  is  also  provided. 
In  section  4,  we  investigate  properties  of  reasoning 
about  authorizations  in  object  oriented  databases  and 
illustrate  a  case  study  using  our  formalism.  Finally, 
we  discuss  some  related  work  and  our  future  work  in 
section  5  and  section  6  concludes  the  paper. 

2  Formal  Language  C  for  Object  Ori¬ 
ented  Databases  Specification 
2.1  Syntax  of  £ 

The  vocabulary  of  language  £  which  is  used  to  spec¬ 
ify  object  oriented  database  consists  of: 

1.  A  finite  set  of  object  variables  OV  =  {o,  o\,  oi,  •  *  •} 
and  a  finite  set  of  object  constants  OC  = 
{0, 0i,  02)  *  *  •}•  We  will  simply  name  O  =  OV  U 
OC  as  object  set 

2.  A  finite  set  T  of  function  symbols  as  object  con¬ 
structors  or  methods  where  each  /  e  T  takes  ob¬ 
jects  as  arguments  and  maps  to  an  object  or  a  set 
of  objects. 
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3.  Auxiliary  symbols  =^>  and  »-*■. 

An  object  proposition  is  an  expression  of  the  form 
0  has  method  /i(*  •  •)  =>  Ill, 

fm{-  ■  ■)  =>  nm, 
fm+ 1(-  •  •)  *-+  nm+i, 

/»(---)->n„.  (1) 

In  (1)  0  is  an  object  from  O  and  /i ,  ■  •  * ,  fm ,  •  ■  ■ ,  fn 
are  function  symbols.  Each  function  symbol  /  takes 
objects  as  arguments  and  maps  to  some  II  that  is  an 
object  or  a  set  of  objects.  In  an  object  proposition,  a 
method  with  the  form  /(*■*)  =>  II  indicates  that  f7 s 
arguments  represent  the  types  of  actual  objects  that 
should  be  taken  in  any  instance  of  this  object  propo¬ 
sition,  and  /  returns  a  set  of  types  of  the  resulting 
object /objects.  On  the  other  hand,  a  method  with 
the  form  /(•  •  *)  II  indicates  that  /  takes  actual  ob¬ 
jects  as  arguments  and  returns  an  actual  object  or  a 
set  of  objects.  For  example,  the  following  is  an  object 
description  about  a  PhD  student: 

PhDStd  has  method  name  String , 

area(Staff)  =>  String, 
first  degree  *-$■  7 Bachelor7, 

where  name  =>  String  represents  that  the  type  of 
name  is  a  string,  and  method  area  takes  type  Staff 
(i.e.  another  object,  eg.  the  student’s  supervisor)  as  a 
parameter  and  returns  a  type  of  string  to  indicate  the 
research  field,  while  firstdegree  — >  'Bachelor7  simply 
expresses  that  every  PhD  student  should  hold  a  Bach¬ 
elor  degree.  An  object  proposition  is  called  ground  if 
there  is  no  object  variable  occurrence  in  it. 

An  isa  proposition  of  C  is  an  expression  of  one  of 
the  following  two  forms: 

O  isa  member  of  C ,  (2) 

O  isa  subclass  of  C,  (3) 

where  O  and  C  are  objects  from  O ,  i.e.,  O  and  C  may 
be  object  constants  or  variables.  Clearly,  isa  propo¬ 
sitions  (2)  and  (3)  explicitly  represent  the  hierarchy 
relation  between  two  objects.  An  isa  proposition  with¬ 
out  containing  any  object  variables  is  called  ground  isa 
proposition . 

We  call  an  object  or  isa  proposition  a  data  proposi¬ 
tion.  A  data  proposition  is  called  ground  data  propo¬ 
sition  if  there  is  no  object  variable  occurrence  in  it. 


We  usually  use  notation  <j>  to  denote  a  data  propo¬ 
sition.  We  assume  that  any  variable  occurrence  in  a 
data  proposition  is  universally  quantified. 

A  constraint  proposition  is  an  expression  of  the  form 

$  if  far- -,4k,  (4) 

where  $,<(>1,"  •  ,<f>k  are  data  propositions.  A 
constraint  proposition  represents  some  relationship 
among  different  data  objects.  With  this  kind  of  propo¬ 
sition,  we  can  represent  some  useful  deductive  rules  of 
the  domain  in  our  database.  A  database  proposition 
is  an  object  proposition,  isa  proposition,  or  constraint 
proposition. 

We  can  now  formally  define  our  object  oriented 
database  as  follows. 

Definition  1  An  object  oriented  database  E  is  a 
triplet  (T,  A,f2),  where  T  is  a  finite  set  of  ground  ob¬ 
ject  propositions ,  A  is  a  finite  set  of  ground  isa  propo¬ 
sitions ,  and  Q  is  a  finite  set  of  constraint  propositions. 

Example  1  We  consider  a  simplified  domain  about 
research  people  in  a  computer  science  department. 
The  structure  of  such  domain  is  illustrated  as  the  fol¬ 
lowing  figure. 


Figure  1:  A  research  people  database. 

In  Figure  1,  line  arrows  indicate  subclass  relations 
while  dot-line  arrows  indicate  membership  relations  in 
the  database. 

Using  our  language  £,  our  database  E  =  (T,  A,  12) 
is  specified  as  follows: 

(1)  the  set  of  ground  object  propositions  T  consists  of: 

ResPeople  has  method  name  =>  String , 

age  =>  Integer, 

firstdegree  9 Bachelor 7,  (5) 

Postgraduate  has  method  id  =>  Integer, 
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degree  String , 
area(Staff)  =>  String .  (6) 

Staff  has  method  (7) 

research  =>  {SYriny,  •  •  - ,  5trmy} 
teaching  =>  {Strmy,  •  ■  • ,  5/rzny}, 

salary  =>  String ,  (8) 

Tutor  has  method  topsalary  >-4  ’$45,000',  (9) 

Lecturer  has  method  topsalary  1-4  ’$58, 000  \  (10) 

professor  has  method  topsalary  j->  ’$85,000’,  (11) 

(12) 

Tom  has  method  name  h->  ’Tom’, 

age  1-4  21, 
id  96007, 
degree  1-4  'Master', 
area(Peter)  1-4  ' Database ',  (13) 

Sue  has  method  name  ^4  'Sue', 
aye  h4  24, 
id  1-4  95012, 
degree  1-4  'P/lD', 
area  (James)  »-4  ’Security’, 

salary  1-4  '#35,000',  (14) 

Faye  has  method  name  1-4  ’Faye’, 

age  »-4  30, 
research  *-4  {  Wetiuor&my'}, 
teaching  »-4  {  'CS7',  'CS2*}, 

salary  M-  ’$43,000’,  (15) 

James  has  method  name  i-4  ’James’, 

age  »-4  42, 

research  >-4  {  ’Security’,  ’Networking’}, 

Teaching  »-4  {  WetiyorAriny^}, 

salary  h4  ’$78,000’,  (16) 

(2)  the  set  of  ground  isa  propositions  A  consists  of: 

Tom  isa  member  of  Postgraduate ,  (17) 


Sue  isa  member  of  Postgraduate ,  (18) 

Sue  isa  member  of  Tutor,  (19) 
Faye  isa  member  of  Tutor,  (20) 
^4nn  isa  member  of  Lecturer ,  (21) 

James  isa  member  of  Professor ,  (22) 

Postgraduate  isa  subclass  of  ResPeople,  (23) 
Staff  isa  subclass  of  ResPeople ,  (24) 

Tutor  isa  subclass  of  Staff,  (25) 
Lecturer  isa  subclass  of  Staff ,  (26) 

Professor  isa  subclass  of  Staff ,  (27) 

(3)  ft  consists  of  two  constraint  propositions: 

y  isa  member  of  Staff 
if  x  isa  member  of  Postgraduate, 

x  has  method  area(y)  >-4  z,  (28) 
y  has  method  research  »-4  {...,  z, ...} 
if  x  isa  member  of  Postgraduate, 

x  has  method  area(y)  >-4  z,  (29) 

where  x,y  and  z  are  object  variables,  and  notation 
z , ...}  means  that  set  {...,  z, ...}  includes  element  z 
while  other  elements  in  the  set  are  not  interested  in 
here. 

In  database  E,  we  assume  that  objects  Integer 
and  String  be  primitive  object  constants  that  we  do 
not  need  to  give  explicit  descriptions.  That  is,  we 
omit  isa  propositions  like  21  isa  member  of  Integer, 
’Tom  'isa  member  of  String  from  our  database.  Our 
database  also  presents  necessary  inheritance  proper¬ 
ties  among  different  objects.  For  instance,  since  object 
Tom  is  a  member  of  Postgraduate,  it  should  inherit 
method  firstdegree  >-4  ’Bachelor’.  The  semantics  of 
inheritance  will  be  described  in  next  subsection. 

Finally,  in  E,  V  and  A  represent  explicit  data  object 
descriptions  and  hierarchical  relations  among  these 
objects,  while  ft  describes  constraints  of  the  domain 
which  characterize  some  implicit  data  objects  an  d 
their  properties.  By  using  these  rules  in  ft  and  facts 
in  T  U  A,  we  actually  can  derive  new  data  objects 
with  some  clear  properties.  For  instance,  in  the  above 
database,  we  do  not  give  explicit  description  about  ob¬ 
ject  Peter.  But  from  proposition  (13)  and  (17)  about 
object  Tom,  we  can  derive  the  facts  that  Peter  is  a 
member  of  Sta  ff  and  has  a  research  field  ’Database 
■ 

2.2  Semantics  of  C 

In  this  subsection,  we  define  the  semantics  of  our 
database  language  C  by  following  a  similar  way  in  clas¬ 
sical  logic. 
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Definition  2  Let  L  be  an  object  oriented  database 
language  we  defined  earlier.  A  structure  of  C  is  a 
tuple  /  =  ({/, »->/),  where 

f.  {/  a  nonempty  set  called  the  universe  o//  that 
representing  the  set  of  all  actual  objects  in  the 
domain. 

2.  For  each  n-ary  function  symbol  f  in  T ,  there  ex¬ 
ists  a  n-ary  function  fj:  Un  U  in  Tj .  For 
n  —  0,  fi  is  an  element  ofU. 

3.  Cu  is  a  partial  ordering  on  U  and  Eu  is  a  binary 
relation  on  U.  We  require  that  if  a  Eu  b  and 
b  Cu  c ,  then  a  Eu  c. 

4.  For  symbol  =>  in  £,  =>/  is  a  map:  =>/;  U  — > 

(ifo,  *  *  *  •  *);  where  each  #,•  is  a  set  0/(2  + 1)- 

ary  anti-monotonic  functions  with  respect  to  or¬ 
dering  C |7 1  such  that  for  every  hi  E  Hi, 

hull**1  ->VUU),  (30) 

in  which  V  |  (J7)  is  the  set  of  all  upward-closed 
subsets  of  U  with  respect  to  Cu- 

5.  For  symbol  »— >-  in  C,  is  a  map:  {/  — > 
(Go,  *  *  Gk,  •  *  •)>  where  Gk  is  a  set  of  (k  +  l )-ary 
functions  such  that  for  every  gk  €  Gk, 

gk  :Uk+1  -^UUV(U),  (31) 

in  which  V{U)  is  the  set  of  all  subsets  ofU . 

Now  let  us  look  at  this  definition  more  closely.  In  a 
structure  /,  U  represents  all  possible  actual  objects  in 
the  domain.  That  is,  each  element  in  U  is  a  real  object 
in  our  world.  Then  a  function  symbol  (i.e.  object 
constructor)  /  in  T  is  corresponding  to  a  function  // 
in  Ti.  Note  that  /  takes  object  constants  or  variables 
in  O  as  arguments  while  //  takes  elements  in  U  as 
arguments  and  returns  an  element  of  U .  The  function 
of  ordering  C u  is  to  represent  the  semantics  of  isa 
subclass  proposition  in  i C.  For  example,  a  C u  b  is  the 
counterpart  of  proposition  A  isa  subclass  of  B ,  while 
A  and  B  are  elements  in  G  (i.e.  object  constants  or 
variables)  and  are  mapped  to  a  and  b,  which  are  the 
elements  of  U  respectively.  We  also  write  a  Cu  b  if 
a  Cu  b  but  azfzb.  The  semantics  of  isa  membership 
proposition  in  C  is  provided  by  Eu  in  I  in  a  similar 
way. 

The  semantics  of  =>,  however,  is  not  quite  straight¬ 
forward.  As  we  mentioned  earlier,  a  method  with  the 
form  /(•*•)  II  actually  defines  the  function  type 

1That  is,  if  u,v  E  U 1+1  and  v  Cu  u,  then  hi(v)  D  hy(u ). 


of  /.  That  is,  /  takes  objects  that  represent  types  of 
actual  objects  and  returns  an  object  (or  a  set  of  ob¬ 
jects)  that  indicates  the  type  (or  types)  of  resulting 
actual  object  (or  objects).  Suppose  /  is  a  i- ary  func¬ 
tion.  Then  the  semantics  of  =>  is  provided  by  mapping 
that  maps  the  resulting  object  represented  by 
/(♦*•)  to  a  (i  +  l)-ary  function  hi  :  Ul+1  — >  V  t  {U), 
where  the  first  ith  arguments  in  U1+l  are  objects  that 
corresponds  to  the  i  arguments  taken  by  /,  and  the 
(i  +  l)-th  argument  in  is  the  object  that  corre¬ 
sponds  to  the  object  associated  with  function  /(•••)  in 
the  proposition  (we  also  call  the  host  object  of  /).  In 
/(••*)  =>  II,  II  denotes  the  type/types  of  resulting  ob¬ 
ject/objects  for  which  we  use  a  subset  of  U  to  represent 
all  the  possible  actual  objects  that  have  type/types  in¬ 
dicated  by  II. 

It  is  important  to  note  that  we  require  the  subset 
of  U  to  be  upward-closed  with  respect  to  ordering  Cu  - 
A  subset  V  of  U  is  upward-closed  if  for  v  E  V  and 
v  Cu  v then  v*  E  V .  The  purpose  of  this  requirement 
is  that  if  V  is  viewed  as  a  set  of  classes,  upward  closure 
ensures  that  for  each  class  v  E  V,  V  also  contains  all 
the  superclasses  of  vy  which  will  guarantee  the  proper 
inheritance  property  of  types. 

A  similar  explanation  for  ►->/  can  be  given  for  the 
semantics  of  »-*.  We  now  show  that  =>/  actually  pro¬ 
vides  the  type  of  the  corresponding  *->/. 

To  simplify  our  formalization,  we  will  use  Herbrand 
universe  in  any  structures  of  C.  That  is,  the  Herbrand 
universe  Uh  is  formed  from  the  set  of  all  object  con¬ 
stants  in  OC  and  the  objects  built  by  function  symbols 
on  these  object  constants. 

Definition  3  Let  I  =  ( Uh ,  Fif  Cj,  Ej,  =>/,  >->/)  be  a 
structure.  We  define  entailment  relation  as  follows. 

1 .  For  a  ground  isa  membership  proposition,  I  0 
isa  member  of  C  if  O  EuH  C ,  and  for  a  isa 
subclass  proposition,  I  O  isa  subclass  of  C  if 

o  cUh  c3. 

2.  For  a  ground  object  proposition, 

I  \=  O  has  method  /i(*  •  •)  =>■  Hi, 

*  j 

fm  (*  *  ')  nm  j 

fm+ 1(*  *  •)  nm+1, 

’  J 

/n(***)  *->  nn 

2In  expression  =>/:  U  (Hq,-  *  ••)>  we  use  notation 

to  denote  the  t-th  component  of  =^/,  i.e.  =>j^:  U  -*>  Hi. 

3Note  that  under  Herbrand  universe  Uh,  an  object  constant 
is  mapped  to  itself  in  Uh  - 
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if  the  follo  wing  conditions  hold: 


•  for  each  /(Oi, 

■■;0P) 

where 

f 

is  in 

{/!,-• 

'  >  fm  }  > 

=4P) 

(0r)(0 1,. 

■■,Op,0) 

= 

n, 

where 

■••>Op)  = 

O' ,  and 

#  for  each 

■■■,o’g) 

where 

/ 

is  in 

{fm- {-1 

J  ■  ■  ■  l  fn } ; 

■■,0'g,0) 

= 

ir, 

where 

3.  For  a  ground  constraint  proposition ,  I  \=  (p  if 
4>ir  •  •  Ak  if  I  f=  <f>i,  •••,/( =  4>k  implies  I  (=  <p. 

f  For  any  proposition  ip  including  object  variables , 
/  |=  ip  if  for  every  instance  (p  of  ip  (i.e.  <p  is 
obtained  from  ip  by  substituted  each  variable  in  ip 
with  some  element  ofUfj)j  I  N  <t>- 

Now  we  can  formally  define  the  model  of  a  database 
E  as  follows: 

Definition  4  A  structure  M  of  C  is  a  model  of  a 
database  E  =  (r,  A,  Cl)  if 

1.  For  each  proposition  ip  in  TUAUfi,  M  (=  ip. 

2.  For  each  object  proposition  <p,  if  M  |=  <p,  then 
M  <pr  where  <p'  is  obtained  from  <p  by  omitting 
some  methods  of  <p. 

3 .  For  any  isa  proposition  O  isa  member  of  C  and 
object  propositions  C  has  method  /(•••)  =$►  II 
and  C  has  method  /(•  ••)»-*>  II, 

(1)  M  \=  O  isa  member  of  C  and  M  \=C  has 
method  /(•••)=>•  II  imply  M  \=  O  has  method 

/(•••)  =*n; 

(2)  M  O  isa  member  of  C  and  M  \=  C  has 
method  /(*  •  •)  h4  II  imply  M  \=  O  has  method 

/(■■•)-+  n. 

4 ■  for  any  isa  proposition  O  isa  subclass  of  C  and 
object  proposition  C  has  method  /(*--)  i-4  II, 
M  |=  O  isa  subclass  of  C  and  M  f=  C  has 
method  /(•  •*)►->  II  imply  M  (=  O  has  method 

/(•  ••)-*■ n- 

Condition  1  in  the  above  definition  is  the  basic  require¬ 
ment  for  a  model.  Condition  2  allows  us  to  partially 
represent  an  object  with  only  those  methods  that  are 
of  interest  in  a  given  context.  Condition  3  is  a  restric¬ 
tion  to  guarantee  necessary  inheritance  of  member¬ 
ship,  whereas  Condition  4  is  needed  for  the  purpose  of 
subclass  value  inheritance. 

Let  E  be  a  database  and  <p  be  a  database  proposi¬ 
tion.  If  for  every  model  M  of  E,  M  f=  <£,  we  also  call 
that  <p  Is  entailed  by  E,  denoted  as  E  <p. 


3  Databases  with  Associated  Autho¬ 
rizations 

In  this  section,  we  extend  language  C  to  Ca  to  in¬ 
clude  authorization  in  object-oriented  databases. 

3.1  Syntax  of  Ca 

The  vocabulary  of  Ca  includes  the  vocabulary  of  C 
together  with  the  following  additions: 

1.  A  finite  set  of  subject  variables  <SV  = 

{•$,  Si ,  '  *  *}  and  a  finite  set  of  subject  constants 

SC  —  {5,  Si ,  So,  *  *  *}*  We  denote  S  =  SV  U  SC. 

2.  A  finite  set  of  access-rights  variables  AV  — 
{r,  ri,  r2,  *  *  •}  and  a  finite  set  of  access-right  con¬ 
stants  AC  =  {Ry  Ri,  i?2,  *  *  •}.  We  denote  A  = 
AV  U  AC. 

3.  A  ternary  predicate  symbol  holds  taking  argu¬ 
ments  subject,  access-right,  and  object /met hod 
respectively. 

4.  Logic  connectives  A  and  -i. 

In  language  Ca ,  a  fact  that  a  subject  S  has  access 
right  R  for  object  O  is  represented  using  a  ground 
atom  holds(S,  RyO).  A  fact  that  S  has  access  right  R 
for  object  O' s  method  /(•••)  ^  II  is  represented  by 
ground  atom  holds(Sy  R}  0\f).  We  use  ^  for  symbol 
=>  or  •-*. 

In  general,  we  define  an  access  fact  to  be  an  atomic 
formula  holds(Sy  r,  o)  (or  holds($,  ry  <?)/),  where  o\f  in¬ 
dicates  a  method  associated  with  object  o.)  or  its 
negation.  A  ground  access  fact  is  an  access  fact  with¬ 
out  any  variable  occurrence.  We  view  -i-i F  as  F .  An 
access  fact  expression  in  Ca  is  defined  as  follows:  (i) 
each  access  fact  is  an  access  fact  expression;  (ii)  if  ip 
is  an  access  fact  expression  and  <p  is  an  isa  or  object 
proposition,  then  rp  A  <p  is  an  access  fact  expression; 
(iii)  if  ip  and  <p  are  access  fact  expressions,  then  ip  A  <p 
is  an  access  fact  expression.  A  ground  fact  expression 
is  a  fact  expression  with  no  variable  occurrence  in  it. 
An  access  fact  expression  is  pure  if  it  does  not  have  an 
isa  proposition  occurrence  in  it. 

Based  on  the  above  definition,  the  following  are  ac¬ 
cess  fact  expressions: 

holds(Sy  R,  0)  A  OisasubclassofC, 

- *hold$(Sy  Ry  o)  A  oisamemberofC 

where  o  is  an  object  variable. 

Now  we  are  ready  to  define  propositions  in  language 
Ca .  Firstly,  Ca  has  the  same  types  of  database  propo¬ 
sitions  as  Cy  i.e.  object  proposition,  isa  proposition 
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and  constraint  proposition.  It  also  includes  the  fol¬ 
lowing  additional  type  of  access  proposition : 

ii!  implies  <p  with  absence  7,  (32) 

where  xp  is  an  access  fact  expression,  and  <j>  and  7  are 
pure  access  fact  expressions.  Note  that  ip,  <p  and  7 
may  contain  variables.  In  this  case,  as  before,  (32) 
will  be  treated  as  a  set  of  access  propositions  obtained 
by  replacing  tp,  <p  and  7  with  their  ground  instances 
respectively. 

As  an  example,  consider  the  following  access  propo¬ 
sition: 

holds(Sy  Access,  Staf  f\id)  A 
Alice  isa  member  of  Staff 
implies  holds(S ,  Access ,  Alice\id) 

with  absence  -» holds(S ,  Access ,  Alice\id), 

Intuitively,  this  expression  says  that  if  subject  S 
can  access  staff’s  id  record  and  Alice  is  a  member  of 
staff,  then  5  can  also  access  Alice’s  id  record  if  the 
fact  that  S  cannot  access  Alice’s  id  record  does  not 
currently  hold. 

There  is  a  special  form  of  access  proposition  (32) 
when  7  is  empty.  In  this  case,  we  rewrite  (32)  as 

xp  provokes  <py  (33) 

which  is  viewed  as  a  causal  or  conditional  relation  be¬ 
tween  xp  and  <p.  For  instance,  we  may  have  an  access 
proposition  like: 

holds(s ,  r,c)  A  o  isa  subclass  of  c 
provokes  holds(sy  r,  o). 

This  access  proposition  expresses  that  for  any  subject 
s,  access  right  r  and  objects  o  and  c,  if  s  has  access 
right  r  on  c  and  o  is  a  subclass  of  c,  then  s  also  has 
access  right  r  on  o.  This  is  also  an  example  of  access 
inheritance. 

On  the  other  hand,  there  is  also  a  special  form  of 
(32)  when  xp  is  empty.  In  this  case,  we  rewrite  (32) 
simply  as 

always  <j>.  (34) 

For  example,  we  can  express  a  fact  that  the  database 
administrator  (DBA)  should  have  any  access  right  on 
any  object  as  follows: 

always  holds(DBA,  ryo). 


3.2  Databases  with  Associated  Autho¬ 
rizations 

It  is  clear  that  our  access  propositions  (32),  (33) 
and  (34)  provide  flexibility  to  express  different  types 
of  authorization  policies  on  objects.  However,  to  en¬ 
sure  the  proper  inheritance  of  access  policies  on  differ¬ 
ent  objects,  some  specific  types  of  access  policies  are 
particularly  important  for  all  databases.  The  set  of 
these  kinds  of  authorization  policies  is  referred  to  as 
the  generic  authorization  scheme  for  databases.  Con¬ 
sider 

holds(s ,  r,  o)  implies  holds($ ,  r,  o\f) 

with  absence  -^hold$(s,  r,  <?]/).  (35) 

Intuitively,  (35)  says  that  if  s  has  access  right  r  on 
object  0,  then  $  also  has  access  right  r  on  each  of  its 
methods  under  the  assumption  that  ->holds(s,  r,  o\f) 
is  not  present. 

We  also  have  the  following  two  generic  access 
propositions: 

holds(s,  ryc)  Ao  isa  subclass  of  c 
implies  hold$($ ,  r,  0) 
with  absence  -» holds($ ,  r,  0),  (36) 

and 

holds(s,  r,  c\f)  A  o  isa  subclass  of  c 
implies  holds(s ,  r,  o\f) 
with  absence  ~~>hold$(sy  r,  o\f).  (37) 

(36)  and  (37)  guarantee  the  proper  inheritance  of  ac¬ 
cess  policies  on  subclasses. 

Finally,  the  following  two  propositions  ensure  the 
membership  inheritance  of  access  policies. 

holds{$ ,  r,  c)  A  0  isa  member  of  c 
implies  holds(sy  r,  o) 
with  absence  - *holds(sy  r,  o),  (38) 

and 

holds(sy  r,  c\f)  A  o  isa  member  of  c 
implies  holds(s ,  r,  o\f) 
with  absence  -> holds(sy  r,  o\f).  (39) 

Now  we  can  formally  define  our  database  with  asso¬ 
ciated  authorizations  as  follows.  We  will  refer  to  this 
kind  of  database  as  extended  object  oriented  database. 

Definition  5  An  extended  object  oriented  database 
in  La  is  a  pair  A  =  (S,  H);  where  S  =  (f,  A,  ft)  is  the 
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database  as  defined  in  Definition  1,  and  E  =  GA  U  A 
is  an  authorization  description  on  E  where  GA  is  a 
collection  of  generic  authorization  propositions  (35)  - 
(39),  and  A  is  a  finite  set  of  user- defined  access  propo¬ 
sitions. 

3.3  Semantics  of  Ca 

Now  we  consider  the  semantics  of  language  £a .  To 
define  a  proper  semantics  of  our  access  proposition 
(32),  we  need  to  employ  a  fix-point  semantics  that 
shares  the  spirit  of  fix-point  semantics  used  for  ex¬ 
tended  logic  programs  [2,  5]. 

Formally,  a  structure  IA  of  Ca  is  a  pair  (7s,  7“), 
where  7s  is  a  structure  of  £  as  defined  in  Definition  2 
and  7“  is  a  finite  set  of  ground  literals  with  forms 
holds[S,  R,  O),  holds{S,  R,  0\f),  ->holds(S,  R,0)  or 
~>holds(S,  R,  0\f).  Now  we  can  define  the  entailment 
relation  of  Ca. 

Definition  6  Let  IA  =  (7s,  7~)  be  a  structure  of  £° . 
We  define  the  entailment  relation  \=\  of  £a  as  follows. 

1.  For  a  database  proposition  if,  7A  \=\  if  iff  7s  f= 
if. 

2.  For  a  pure  ground  access  fact  expression  if  =  Fx  A 
*  •  *  A  Fk,  where  each  F,  is  a  ground  access  fact , 
IA  |=A  if  iff  for  each  i,  F{  €  7s. 

3.  For  a  ground  access  fact  expression  if,  IA  if 
iff  for  each  isa  or  object  proposition  <f  occurring 
in  if,  7s  (=  <f,  and  for  each  ground  access  fact  <ff 
occurring  in  if,  <f*  £  7“. 

For  an  access  fact  expression  if,  IA  ^=A  if  iff  for 
each  ground  instance  if '  of  if ,  IA  if* . 

Now  we  are  in  the  position  to  formally  define  a  model 
of  A  =  (E,  E). 

Definition  7  Consider  an  extended  database  A  = 
(E,E)  and  a  structure  IA  =  (7s,  7~).  Let  S'  be  an 
authorization  description  obtained  from  E  in  the  fol¬ 
lowing  way: 

(i)  by  deleting  each  access  proposition  if  implies  <f 
with  absence  7  from  E  if  for  some  F;  in  7,  F,-  £ 

734; 

(ii)  by  translating  all  other  access  propositions  if  im¬ 
plies  <f  with  absence  7  to  the  form  if  provokes 
(f,  or  to  the  form  always  <f  if  if  is  empty. 

4  Recall  that  7  =  F\  A  •  *  •  AT*  is  a  pure  access  fact  expression, 
i.e.  each  F{  (1  <  *  <  k)  is  a  ground  access  fact. 


Definition  8  Consider  an  extended  database  A  = 
(E,E)  and  a  structure  7A  =  (7s,  7s).  Let  E'  be  an  au¬ 
thorization  description  obtained  from  E  as  described  in 
Definition  5.  7A  =  (7s,  7~)  is  a  model  of  A  =  (E,  E) 
if  and  only  if 

(i)  7s  is  a  model  of  E; 

(ii)  7“  is  a  smallest  set  satisfying  the  following  con¬ 
ditions: 

(a)  for  each  access  proposition  always  <f  in  E'; 

/AM; 

(b)  for  each  access  proposition  of  the  form  if 
provokes  <f  in  E',  if  IA  |=  if,  then  IA  (=  <f. 

4  Reasoning  about  Authorizations 

In  this  section,  we  investigate  some  properties 
on  the  inheritance  of  authorizations  on  objects  in 
database.  Due  to  space  limit,  we  cannot  provide  com¬ 
prehensive  definitions,  explanation  and  examples  in 
here.  We  just  give  some  theorems  to  conclude  the 
properties  on  the  inheritance  of  authorizations.  For 
the  proofs  of  the  theorems,  refer  to  the  full  paper  [1], 
An  extended  database  may  have  more  than  one 
model.  In  this  case,  every  model  actually  represents 
one  possible  interpretation  for  the  database  with  as¬ 
sociated  authorizations.  However,  a  class  of  extended 
databases  having  unique  models  presents  some  inter¬ 
esting  properties  of  authorizations  with  respect  to  sub¬ 
class  and  membership  relationships  among  objects  in 
databases.  An  extended  database  is  well-specified  if  it 
has  a  unique  model. 

Theorem  1  (Subclass  Authorization^  Let  A  be  a 
well- specified  extended  database  and  S,  R,  C  and  O 
are  arbitrary  subject  constant,  access  right  constant 
and  object  constants  respectively.  Then  the  following 
results  hold. 

(i)  If  A  ^=A  holds(S,  R,  C)  A  O  isa  subclass  of 
C  and  A  \£\  ^holds(S,  R,  O),  then  A 
holds{S ,  R,  O). 

(ii)  If  A  |=a  holds(S}  R,  C\f)  A  O  isa  subclass  of 
C  and  A  \jL\  -iholds(S,  R,  0\f),  then  A  \=\ 
holds(S,R,0\f). 

Theorem  2  (Membership  Authorization^  Let  A 
be  a  well-specified  complex  database,  and  S,  R,  C  and 
O  are  arbitrary  subject  constant,  access  right  constant 
and  object  constants  respectively.  Then  the  following 
results  hold. 
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(i)  If  A  [=a  holds(S,  R,C)  A  O  isa  member  of 
C  and  A  \fc\  -*holds(S,  R,  0),  then  A  (=a 
holds(S ,  /?,  0). 

fii)  //A  }=a  holds(S,  R,  C\f)  A  0  isa  member  of 
C  and  A  ^a  -"'ho/ds(S,  R,  0\f),  then  A  |=a 
holds(S ,  /?,  0|/). 

The  above  two  theorems  directly  follow  from 
generic  authorization  scheme  (35)  -  (39).  The  follow¬ 
ing  two  theorems,  on  the  other  hand,  represent  that 
these  subclass  and  membership  authorization  can  be 
overridden  such  that  the  consistency  of  authorizations 
can  be  maintained. 

Theorem  3  ^Overriding  of  Subclass  Authoriza¬ 
tion,)  Let  A  be  a  well-specified  complex  database,  and 
S,  R,  C  and  O  are  arbitrary  subject  constant ,  access 
right  constant  and  object  constants  respectively.  Then 
the  following  results  hold. 

(i)  If  A  ^=a  holds(S,  R,C)  A  0  isa  subclass 
of  C  and  A  ^a  holds(S,  R,0),  then  A 

-> hold$(S ,  R,  O). 

(ii)  If  A  [=a  holds(S,  R,  C\f)  A  0  isa  subclass 
of  C  and  A  ^a  holds(S,  R,  0\f),  then  A  ^=a 
-ikolds(S,  R,  0\f). 

Theorem  4  ^Overriding  of  Membership  Autho¬ 
rization^)  Let  A  be  a  well- specified  complex  database , 
and  S,  R,  C  and  0  are  arbitrary  subject  constant ,  ac¬ 
cess  right  constant  and  object  constants  respectively. 
Then  the  following  results  hold. 

(i)  If  A  ^=a  holds(S,R,C)  A  0  isa  member 
of  C  and  A  ^a  holds(S,  R,  O),  then  A  (=a 
- 'hold$(S ,  R,  0). 

(ii)  If  A  [=a  holds(S,  R,  C\f)  A  0  isa  member 
of  C  and  A  ^a  holds(S,  R,0\f),  then  A  (=a 

holds{S,R,0\f ). 

Now,  we  revisit  the  research  people  database  do¬ 
main  discussed  in  Example  1.  We  will  consider  a  set 
of  authorizations  on  objects  in  this  database  and  show 
how  our  approach  can  be  used  to  reason  about  autho¬ 
rizations  in  this  object  oriented  database  environment. 

Example  2  Research  people  database  domain 
revisited.  Consider  an  extended  research  people 
database  A  =  (E,E),  where  E  is  specified  to  be  the 
database  described  in  Example  1,  and  E  is  a  set  of 
authorization  policies  on  E. 

We  assume  that  in  this  domain,  there  are  three  lay¬ 
ers  of  subjects: 


Figure  2:  A  complex  research  people  database. 


(i)  A  super  user  called  a  database  administrator 
DBA ,  who  can  read  and  update  class  ResPeople 
and  all  its  subclasses  and  members  through  in¬ 
heritance; 

(ii)  A  student  administrator  StdAdm  who  can  read 
and  update  class  Postgraduate  and  all  its  mem¬ 
bers  through  the  inheritance.  An  academic  ad¬ 
ministrator  AcaAdm  who  can  read  and  update 
class  Staff  and  all  its  subclasses  and  members 
through  inheritance. 

(iii)  Five  individual  users  named  T ,  S,  F,  P  and  J  in¬ 
dicating  people  Tom,  Sue,  Faye,  Peter  and  James 
respectively,  who  can  read  their  own  objects 
Tom,  Sue,  Faye,  Peter  and  James . 

The  structure  of  this  extended  database  is  shown  in 
Figure  2. 

Now  we  can  specify  E  as  follows.  Let  E  =  GA  U  A, 
where  GA  is  a  collection  of  (35)  -  (39)  (i.e.  generic  au¬ 
thorization  scheme).  Based  on  the  above  descriptions 
(i),  (ii)  and  (iii),  A  should  include  the  following  access 
propositions: 

always  holds(DBA ,  Read ,  ResPeople),  (40) 
always  holds(D BA,  Update,  ResPeople),  (41) 
always  holds(StdAdm,  Read,  Postgraduate),  (42) 
always  holds(StdAdm,  Update,  Postgraduate),  (43) 
always  hold$(AcaAdm,  Read,  Staff),  (44) 
always  holds(AcaAdm,  Update,  Staff),  (45) 
always  holds(T,  Read,  Tom),  (46) 
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always  holds(S,  Read,  Sue),  (47) 
always  holds(F,  Read,  Faye),  (48) 
always  hoi ds{P,  Read,  Peter),  (49) 
always  holds(J,  Read,  James).  (50) 

(iv)  Observing  our  database  structure,  it  is  also 
clear  that  Sue  belongs  to  two  different  classes 
Postgraduate  and  Tutor.  Due  to  the  member¬ 
ship  authorization  inheritance  property,  it  turns 
out  that  subject  StdAdm  can  read  and  update 
all  methods  of  Sue  that  are  inherited  from  classes 
Staff  and  Tutor.  Clearly,  this  is  not  our  expec¬ 
tation  since  intuitively,  a  student  administrator  is 
not  usually  allowed  to  access  some  staff’s  informa¬ 
tion  (e.g.  salary).  This  problem  can  be  avoided 
easily  by  including  the  following  proposition  in  A: 

o  isa  member  of  Staff  implies 

-> 'holds(StdAdm ,  r,  o\salary) .  (51) 

(v)  Furthermore,  if  some  staff  is  the  supervisor  of  a 
postgraduate  student,  this  staff  should  be  able  to 
read  all  information  about  his/her  student  unless 
there  is  an  explicit  declaration  denying  this.  So 
A  also  includes  one  more  access  proposition: 

holds(s ,  read,  o')  A  (52) 

o'  isa  member  of  Staff  A 
o  isa  member  of  Postgraduate  A 
o  has  method  area(of)  II 
implies  kolds($,  Read ,  o) 
with  absence  holds(s,  Read ,  o).  (53) 

Now  we  have  a  complete  specification  for  this  extended 
research  people  object  oriented  database.  It  can  be 
proved  that  this  database  is  well-specified.  That  is,  A 
has  a  unique  model.  The  following  results  show  that  A 
indeed  presents  the  desired  authorization  policies  on 
objects  in  the  database. 

(a)  DBA  can  read  and  update  every  postgraduate 
student  and  staff  members’  objects  and  all  their 
methods  inherited  from  all  of  their  superclasses, 
i.e. 

A  \=x  holds(DB A,  Read/Update,  0)s,  and 
A  [=a  holds{DB A,  Read/Update,  0\f), 
where  O  is  any  object  constant  in  A  and  /  is  any 
method  associated  with  0. 

sIt  denotes  holds(DBA,  Read,  O)  and 

holds(DBAj  Update, O). 


(b)  StdAdm  can  read  and  update  every  student  mem¬ 
ber  object,  i.e. 

A  f=A  holds(StdAdm,  Read /Update,  O), 
where  O  is  Tom  or  Sue ,  which  also  implies  that 
StdAdm  can  also  read  and  update  all  methods 
of  Tom  and  Sue  inherited  from  their  superclasses 
ResPeople  and  Postgraduate,  i.e. 

A  f=A  holds{StdAdm,  Read /Update,  0\f). 

But  StdAdm  cannot  read  and  update  5ue’s  salary 
which  is  inherited  from  class  Sta ff: 

A  [=a  ^holds(StdAdm,  Read/ Update, 
Sue\salary) . 

(c)  AcaAdm  can  read  and  update  staff  members 
Faye  and  James ,  i.e. 

A  (=a  holds(AcaAdm,  Read/Update,  Faye), 
and 

A  |=a  holds(AcaAdm,  Read /Update,  James), 
which  also  imply  that  AcaAdm  can  also  read 
and  update  all  methods  of  Faye  and  James. 
Note  that  since  there  is  no  explicit  description 
about  object  Peter,  AcaAdm  cannot  access  ev¬ 
ery  method  of  Peter. 

(d)  For  every  individual  user  (i.e.  T,S,F,P  and  J), 
he/she  can  read  his/her  corresponding  object  and 
all  its  methods  inherited  from  all  its  superclasses, 
i.e. 

A  \=\  holds(T,  Read,  Tom), 

A  |=a  holds(T,  Read,Tom\f), 

’j 

A  [=a  holds(J,  Read,  James), 

A  J=a  holds(J,  Read,  James\f), 
where  /  denotes  any  of  the  method  associated 
with  the  corresponding  object. 

(e)  Every  supervisor  can  read  his/her  student  ob¬ 
ject’s  all  methods,  i.e. 

A  ^a  hold$(P,  Read,  Tom\f)  and 

A  [=A  holds(J,  Read,  Sue\f), 
where  /  and  /'  denotes  any  method  of  Tom 
and  Sue  respectively.  Note  that  A  \=\ 
holds(P,  Read,Tom\f)  is  derived  from  the  fact 
that 

E  \=  Peter  isa  member  of  Staff. 


5  Discussions  and  Future  Work 

Here,  we  briefly  review  some  related  work,  dis¬ 
cuss  the  different  approaches  used  in  object-oriented 
database  security,  and  outline  our  future  work. 

In  [3],  a  security  model  for  object-oriented 
databases  was  proposed.  This  model  consists  of  a  set 
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of  policies,  a  structure  for  authorization  rules  and  an 
algorithm  to  evaluate  access  requests.  The  database 
is  composed  of  objects  that  include  a  collection  of 
facts  and  a  collection  of  relevant  rules.  An  object 
binds  knowledge  rules  to  database  facts.  The  database 
is  specified  by  the  OSAM*  [10,  11]  model,  in  which 
the  generic  properties  are  defined  through  a  gener¬ 
alization  association  and  the  set  of  attributes  of  a 
class  is  defined  by  an  aggregation  association .  Derived 
classes  (subclasses)  are  viewed  as  generic.  Class  inheri¬ 
tance  properties  suggest  that  access  to  some  attributes 
of  a  class  also  implies  access  to  the  corresponding  val¬ 
ues  in  its  subclass.  Generally,  there  are  three  types  of 
access  policies: 

1.  A  user  who  has  access  to  a  class  is  allowed  to 
have  similar  type  of  access  in  the  corresponding 
subclasses  to  the  attributes  inherited  from  that 
class. 

2.  Access  to  a  complete  class  implies  access  to  the 
attributes  defined  in  that  class  as  well  as  to  at¬ 
tributes  inherited  from  a  higher  class. 

3.  An  attribute  defined  for  a  subclass  is  not  accessi¬ 
ble  by  accessing  any  of  its  superclass. 

In  our  model,  we  have  considered  similar  access 
policies  via  subclass  and  membership  relationship  au¬ 
thorization  rules.  These  rules  are  specified  by  the  the¬ 
orems  of  subclass  authorization,  membership  autho¬ 
rization,  overriding  subclass  authorization  and  over¬ 
riding  membership  authorization.  In  particular,  our 
Theorem  1  and  Theorem  3  capture  the  above  three 
types  of  access  policies.  Our  model  is  based  on  our 
previous  work  of  formal  specification  for  authorization 
policies  and  their  transformations,  and  is  discussed 
from  authorization  specification  point  of  view.  How¬ 
ever,  in  practice,  the  access  policies  are  organizational 
dependent.  They  can  vary  from  organization  to  orga¬ 
nization  and  can  also  vary  depending  on  the  type  of 
applications. 

The  access  policies  that  we  have  considered  in  this 
paper  are  based  on  subject  authorization  viewpoint. 
In  practice,  both  subject  and  object  can  be  in  a  hier¬ 
archy  structure.  From  object-oriented  system  view¬ 
point,  access  propagation  is  also  data  structure  re¬ 
lated.  In  our  model,  authorization  propagation  from 
object  viewpoint  can  also  be  specified.  For  instance, 
there  is  an  object  folder ,  the  folder  contains  a  number 
of  documents ,  each  document  contains  a  number  of 
files.  We  can  also  specify  authorization  propagations 
based  on  the  hierarchical  structure.  For  example,  the 
documents  can  be  viewed  as  subclasses  of  class  folder . 


If  the  folder  can  be  accessed,  then  the  document  could 
also  be  accessed.  This  can  be  specified  as: 

holds(s ,  acess ,  Folder)  implies 
holds(s ,  access ,  Document ). 

In  our  future  work,  we  intend  to  consider  attributes 
for  other  types  of  associations.  In  particular,  we  will 
consider  in  more  detail  the  generalization  and  aggrega¬ 
tion  associations.  In  addition,  the  placement  of  the  au¬ 
thorization  policies  also  needs  to  be  addressed.  They 
may  be  placed  in  a  special  class  or  a  class  they  re¬ 
fer  to,  or  propagated  through  the  hierarchy  structure. 
Furthermore,  we  have  not  investigated  the  access  to 
the  authorization  system  itself  yet.  This  will  also  be 
considered  in  our  future  work. 

6  Conclusions 

In  this  paper,  we  have  proposed  a  logical  formal¬ 
ization  for  specifying  authorizations  in  object  oriented 
databases.  Our  work  consisted  of  two  steps:  the  first 
step  involved  a  formal  language  £  to  formalize  object 
oriented  databases.  We  provided  a  high  level  language 
to  specify  an  object  oriented  database  and  defined  a 
precise  semantics  for  it.  Our  semantics  of  £  shares 
some  features  of  Kifer  et  aVs  F-logic  for  specifying  ob¬ 
ject  oriented  databases.  But  our  database  specifica¬ 
tion  is  more  succinct  and  intuitive,  and  hence  it  has 
been  possible  to  extend  this  by  combining  it  with  the 
authorization  structures.  The  second  step  extends  £ 
to  language  Ca  by  representing  different  types  of  au¬ 
thorizations  in  the  database.  It  has  been  shown  that 
the  types  of  authorizations  in  our  formalism  are  quite 
flexible  and  can  be  used  to  reason  about  complex  au¬ 
thorizations  compared  with  other  approaches. 
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